1。视图层是一有html，jsp文件组成的，用于显示的
2。控制不是动作所以一定不是Action
（什么叫控制？控制就是老板，老板手下有N个员工，
一个活所有人都有几会去作，但是老板只让张三去作。
所以控制是由actionservlet+struts-config.xml组成的
actionservlet是老板而struts-config.xml是为什么用张三）
3。模型不是Formbean
（什么叫模型？模型就是真实世界在计算机中的影子，
项目中的用户，模型就是真实世界中的某个人，
他要使用系统，那么他就是login
他还要含有用户信息，名子，密码
含有用户信息的是模型？还是能login的是模型？
只有又含有信息又能动作的才是模型
FormBean中只是模型全部信息的一部分
Action只是一条通向动作的一个电话线
只有加上逻辑层后所有的东西才算的上
模型。。。。。。）

另三层架构是什么
application
service
dao
从前面可知这三个加起来才叫业务逻辑
由于业务逻辑复杂性
才把逻辑代码分成了三块。。。。。
（很早以前是都写在action中的
现在把多个action中的代码分出来
另外把相同的代码删去
再分为三层为了删去更多的冗余代码
）
application这东西大约就指调用这个模块的那一句话&之外的其它视图类的东东
如User.login(username,password);
dao数据层。。。。。把数据库的数据变成想要PO，主要是数据读与存
service就是所有的可变他性的东西都放在这里。。。。

Service层是为了处理包含多个POJO对象（即对多个表的数据操作）时，进行事务管理（声明式事务管理）。Service层（其接口的实现类）被注入多个DAO对象，以完成其数据操作。

2, Service之有无

   这一点我的看法未必正确,我的脑海现在有两种构建业务层的模式:

   模式1是Service + DAO,即DAO中只做CRUD及类似的简单操作(称之为功能点,不包含业务逻辑),Service中通过调用一个或多个DAO中的功能点来组合成为业务逻辑.Service的数量应该由功能模块来决定。

   在这种模型中业务逻辑是放在Service中的,事务的边界也应该在Service中控制. 当然,直接在Service中控制事务会引入非业务逻辑的代码,幸好Spring的AOP可以解决这个问题,这也是引入Spring的原因之一.

    如果说到缺点,就在于对某些对象的操作就是简单的CRUD,Service层显得累赘.

    模式2是Service + BO, 而BO = DAO + 业务方法, 在原先DAO的基础上添加业务方法,形成BO对象。需要注意的是BO中的业务方法往往是针对一个实体对象的，如果需要跨越多个实体对象，则方法应该放在Service中。

    举例来说，一个简单的银行帐户管理系统，创建帐户这个BO对象，里面可以有修改密码，取钱等业务方法（不难看出，这些方法都只对单个帐户对象进行操作）。现在需要添加一个转账方法，就应该放在Service中。

    这里Service和BO的关系是什么样的呢？再举一例：以国家行政机关为例：粮食局负责收粮，卖种子等，建设部负责审批土地买卖，建设公路等，这都是行政部分份内的事儿。突然某地发了水灾，救灾时需要粮食局开仓放粮，建设部修建临时房屋，如何协调两个部门？就需要成立专门的救灾委员会，由救灾委员会出面对两个部分的资源进行调拨。这里两个部分就是BO，而救灾委员会就是Service。不知我的意思是否表达准确了，呵呵。

    模式1的在划分Service和DAO时界限清晰，但会带来一些无必要的代码。
    模式2的划分相对复杂，然而可以提高编码效率。

    当然小规模的应用中，没有Service，完全是DAO或BO也是可以接受的。

3，Service和DAO的接口之有无

    接口是一种契约，它可以有多种实现。所以接口之有无取决于具体实现是否需要多样化。如果铁定一种DAO或一种Service只有一种实现，那么抽象出接口的意义不大。然而一些大型应用或许需要DAO和Service的多种实现（比如上面例子中的帐户DAO，可能需要一种Hibernate实现、一种CMP实现和一种JDO实现），为了向上一层隐藏具体实现类，需要采用接口。

    隐藏具体实现类的创建过程，这有两种方法：一是实用工厂方法，代价是代码量大（每个DAO和Service一个工厂）。二是使用Spring的IoC，实现依赖注入，不需要写额外的代码，这也是引入Spring的理由之二。

O/R Mapping 是 Object Relational Mapping（对象关系映射）的缩写。通俗点讲，就是将对象与关系数据库绑定，用对象来表示关系数据。

在O/R Mapping的世界里，有两个基本的也是重要的东东需要了解，即VO，PO。
　　VO，值对象(Value Object)，PO，持久对象(Persisent Object)，它们是由一组属性和属性的get和set方法组成。从结构上看，它们并没

有什么不同的地方。但从其意义和本质上来看是完全不同的。

１．VO是用new关键字创建，由GC回收的。
　　PO则是向数据库中添加新数据时创建，删除数据库中数据时削除的。并且它只能存活在一个数据库连接中，断开连接即被销毁。

２．VO是值对象，精确点讲它是业务对象，是存活在业务层的，是业务逻辑使用的，它存活的目的就是为数据提供一个生存的地方。
　　PO则是有状态的，每个属性代表其当前的状态。它是物理数据的对象表示。使用它，可以使我们的程序与物理数据解耦，并且可以简化对

象数据与物理数据之间的转换。

３．VO的属性是根据当前业务的不同而不同的，也就是说，它的每一个属性都一一对应当前业务逻辑所需要的数据的名称。
　　PO的属性是跟数据库表的字段一一对应的。

PO对象需要实现序列化接口。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

在 struts+ hibernate 这种结构中，是不应该把Hibernate产生的PO直接传递给JSP的，不管他是Iterator，还是List，这是一个设计错误。

我来谈谈在J2EE架构中各层的数据表示方法：

Web层的数据表示是FormBean，数据来源于HTML Form POST
业务层的数据表示是VO
持久层的数据表示是PO，其数据来源于数据库，持久层的数据表示例如CMP

在一个规范的J2EE架构中，不同层的数据表示应该被限制在层内，而不应该扩散到其它层，这样可以降低层间的耦合性，提高J2EE架构整体的

可维护性和可扩展性。比如说Web层的逻辑进行了修改，那么只需要修改FormBean的结构，而不需要触动业务层和持久层的代码修改。同样滴，

当数据库表进行了小的调整，那么也只需要修改持久层数据表示，而不需要触动业务层代码和Web层代码。

不过由于Hibernate的强大功能，例如动态生成PO，PO的状态管理可以脱离Session，使得在应用了Hibernate的J2EE框架中，PO完全可以充当VO

，因此我们下面把PO和VO合并，统称为PO。

先来谈谈ActionFormBean和持久层的PO之间的重大区别。

在简单的应用中，ActionFormBean和PO几乎是没有区别，所以很多人干脆就是用ActionFormBean来充当PO，于是ActionFormBean从JSP页面到

Servlet控制层再到业务层，然后穿过持久层，最后一直映射到数据库表。真是一竿子捅到了底！

但是在复杂的应用中，ActionFormBean和PO是分离的，他们也不可能一样。ActionFormBean是和网页里面的Form表单一一对应的，Form里面有

什么元素，Bean里面就有什么属性。而PO和数据库表对应，因此如果数据库表不修改，那么PO也不会修改，如果页面的流程和数据库表字段对

应关系不一致，那么你又如何能够使用ActionFormBean来取代PO呢？

比如说吧，用户注册页面要求注册用户的基本信息，因此HTML Form里面包含了基本信息属性，于是你需要一个ActionFormBean来一一对应(注

意：是一一对应)，每个Bean属性对应一个文本框或者选择框什么的。

而用户这个持久对象呢？他的属性和ActionFormBean有什么明显不同呢？他会有一些ActionFormBean所没有的集合属性，比如说用户的权限属

性，用户的组属性，用户的帖子等等。另外还有可能的是在ActionFormBean里面有3个属性，分别是用户的First Name, Middle Name, Last

Name，而在我的User这个持久对象中就是一个 Name 对象属性。

假设我的注册页面原来只要你提供First Name，那么ActionFormBean就这一个属性，后来我要你提供全名，你要改ActionFormBean，加两个属

性。但是这个时候PO是不应该修改滴，因为数据库没有改。

那么在一个完整的J2EE系统中应该如何进行合理的设计呢？

JSP(View) ---> ActionFormBean(Module) ---> Action(Control)

ActionFormBean是Web层的数据表示，它和HTML页面Form对应，只要Web页面的操作流程发生改变，它就要相应的进行修改，它不应该也不能被

传递到业务层和持久层，否则一旦页面修改，会一直牵连到业务层和持久层的大面积的代码进行修改，对于软件的可维护性和可扩展性而言，

是一个灾难，Actiont就是他的边界，到此为止！

Action(Web Control) ---> Business Bean ---> DAO ---> ORM --->DB

而PO则是业务层和持久层的数据表示，它在业务层和持久层之间进行流动，他不应该也不能被传递到Web层的View中去，而ActionServlet就是

他的边界，到此为止！

然后来看一看整个架构的流程：

当用户通过浏览器访问网页，提交了一个页面。于是Action拿到了这个FormBean，他会把FormBean属性读出来，然后构造一个PO对象，再调用

业务层的Bean类，完成了注册操作，重定向到成功页面。而业务层Bean收到这个PO对象之后，调用DAO接口方法，进行持久对象的持久化操作。

当用户查询某个会员的信息的时候，他用全名进行查询，于是Action得到一个UserNameFormBean包括了3个属性，分别是first name, middle

name, last name，然后Action把UserNameFormBean的3个属性读出来，构造Name对象，再调用业务Bean，把Name对象传递给业务Bean，进行查

询。

业务Bean取得Name(注意: Name对象只是User的一个属性)对象之后调用DAO接口，返回一个User的PO对象，注意这个User不同于在Web层使用的

UserFormBean，他有很多集合属性滴。然后业务Bean把User对象返回给Action。

Action拿到User之后，把User的基本属性取出(集合属性如果不需要就免了)，构造UserFormBean，然后把UserFormBean

request.setAttribute(...)，然后重定向到查询结果页面。

查询页面拿到request对象里面的ActionFormBean，自动调用tag显示之。

总结：

FormBean是Web层的数据表示，他不能被传递到业务层；PO是持久层的数据表示，在特定情况下，例如Hibernate中，他可以取代VO出现在业务

层，但是不管PO还是VO都必须限制在业务层内使用，最多到达Web层的Control，绝不能被扩散到View去。

FormBean和PO之间的数据转化是在Action中进行滴。

BTW:

JDO1.x还不能像Hibernate功能这样强大，PO不能脱离持久层，所以必须在业务层使用VO，因此必须在业务层进行大量的VO和PO的转化操作，相

对于Hibernate来说，编程比较烦琐。

当然咯，理论是一回事，实际操作也不一定非要这样干，你可以自行取舍，在实际项目中灵活一点，增加一点bad smell，提高开发效率。只不

过在大型项目中最好还是严丝合缝，不然的话，改版的时候会痛苦的很滴。