目前的Web Application大多采用流行的基于B/S模式的三层架构开发，这里的三层架构指的就是Web层、业务层和数据访问层。采用分层的开发方式有很多好处，下面只简单地来说两点：
1：分层开发使不同的开发人员关注他们擅长的特定层面，有助于开发优质的系统。因为很少有程序员可以精通从JS，CSS，DHTML到struts再到 hibernate直至最后的数据库设计这一整套开发流程所要使用到的所有技术。大家各司其职，全力关注自己擅长的层面，这要比一个人或一个小组负责某一模块从页面到最底层的开发方式要好的多。
2：.分层分离了逻辑，使得系统结构层次明晰，系统变得灵活和易于维护。开发人员应该尽量使系统的各层之间保持相对独立的松耦合状态，这是实现分层的必要条件，也是构建良构系统的重要保证。
下面重点说说在各层之间进行数据传递的问题。在讨论这个问题之前我想有必要阐明几个概念，即VO、PO、POJO、BO、DAO、DTO。
VO：值对象（Value Object），另外也有人认为VO指的是View Object，视图对象，亦或者它就是表示两个概念。
PO：持久化对象（Persistence Object）
POJO：（Plain Old Java Object）字面意思应该是无格式的传统Java对象。对于这个概念我看网上有很多人都弄不明白，有的人甚至把它认为是PO，就我个人的理解，我认为 POJO是一个相对概念，就像它的字面意思一样，它指的就一个普普通通的java对象，这一概念主要是用来和像java bean这样遵从特定规范的java objcet进行区别而创造的。
BO：业务对象（Business Object），有人把BO理解成是业务层操纵的数据对象是不对的，BO指的是封装了业务处理逻辑的对象（就是我们要在service层实现的那些类的实例）而业务层操纵的数据对象其实是VO。
DAO就不用多说了（Data Access Object）数据访问对象，
DTO：（Data Transfers Object）数据传输对象。对于这个概念也是比较好理解的，Struts中的ActionForm其实就是一个DTO，用于在页面和Action之间进行数据的传递。另外如果把VO理解成视图对象的话，那么ActionForm就算是VO了。
网上好像还流传一种叫做QO的对象，我想应该指的是（Query Object）查询对象吧，不过我好像真没怎么见过这东西。
弄明白上面几个概念以后，我想说一下这两天一直在考虑的问题，那就是各个层上操纵的数据对象以层与层这间的数据传输问题。
首先来看各层之间操纵的数据对象：
Web层（JSP/Action）：ActionForm
业务层：VO （注意：如果我们使用了Hibernate那么我可以使用它生成的PO来替代业务层的VO，这是因为从结构上讲VO和PO几乎没有什么不同，而又由于 Hibernate的强大功能，使得它的PO可以可以离开持久化层而存在。要知道并不是所有ORM工具都具有这种能力：比如JDO1.x就不可以）
数据访问层：PO。
下面是详细的解说：
ActionForm是Web层的数据表示，他不能被传递到业务层。
PO是持久层的数据表示，在特定情况下，例如Hibernate中，他可以取代VO出现在业务层，但是不管PO还是VO都必须限制在业务层内使用，最多到达Web层的Control（即Action），绝不能被扩散到View去。ActionForm和PO之间的数据转化是在Action中进行的。
其实放开来看，每一层都有自己特定的数据对象，而不是各层共用一种结构的数据对象，这样的话各层之前将严重耦合。在彼此相临的层之间，应该会有这么一个操作过程，即从它的上层或下层接收数据对象，并从中提取出需要的数据封装进自己层要操纵的数据对象里。例如在Action中就是这样做的，但由于业务层和数据访问层使用了同一种数据访问对象而省去了这种操作。
这里的焦点是Action，我们在Action要的做工作是：接受从页面传来的ActionForm，从中取出数据，封装到PO中，然后调用业务层组件（BO）实现相关业务，最后进行页面跳转。