Model 1, Model 2和Model 2x

本想看关于DTO的文档，想不到这篇文档对Model 1, Model 2和Model 2x的描述写的很好，于是copy下来。

 

Model 1
Model 1的基础是JSP文件，它由一些相互独立的JSP文件，和其他一些Java Class组成（不是必须的）。这些JSP从HTTP Request中获得所需要的数据，处理业务逻辑，然后将结果通过Response返回前端浏览器。

Model 1的应该说是唯一的好处是"简单"，可以大大加快系统的开发进度。它把表现层和业务逻辑层柔和在一起，不利于以后的维护工作以及开发角色的分配，所以这种模式只能适合于小的系统开发。

Model 2
采用面向对象技术实现MVC模式从而扩展JSP/Servlet的模式被成为是Model 2模式。Apache Jakarta项目中Struts是一个实现Model 2的很好的框架，它通过一些Custom Tag Lib处理表现层，用ActionFrom Bean表示数据，用自己提供的一个ActionServlet作为控制器实现页面的流转的控制功能。

Struts强制开发人员采用MVC的设计进行系统开发，虽然它会带来如将表现层和业务层分开，合理安排开发人员角色等诸多方面的好处，但也存在一些缺点：

1. 由于View层采用JSP，所以开发人员还是可以在其中写上一大堆的Java代码，从而使最后的系统还处于一种混乱的状态。而实际上开发人员确实会出现这种状况；
2. 开发人员需要学习Struts提供的Custome Tag Lib，这需要时间，尤其对以前只熟悉HTML的页面设计人员来说，同时其中的一些Tag已经被Java Standard Tag Library取代掉了。

Model 2x
将Struts中的View层用XML/XSLT技术替换掉，这就是我们要提到的Model 2x模式。Apache Cocoon是Jakarta项目组提供的另外一套XML技术框架，配合Struts一起使用，将很好的解决我们上面遇到的这些问题。

这样的结构会带来如下一些优点：

1. 避免了开发人员将逻辑代码直接写在JSP中，从而明晰地划分了业务逻辑层和表现层的界限。后台的Java程序员只需要关心业务逻辑的实现，最后将结果用XML来表示；而页面设计人员只需要关心如何美化页面，只要双方定义好中间的数据接口；
2. 借助XSLT，开发人员可以完全不用学习Struts提供的那些已经不标准的Custom Tag。这个问题我们可以从输入页面和输出页面来考虑。对于输入，不管我们的JSP页面（对于Struts来说）采用什么样的技术，最终在浏览器中显示的始终是HTML，那么我们完全可以不用Struts提供的例如html:form等Tag，而是直接用HTML来描述，只要我们注意表单（form）中的字段和ActionForm中属性之间的对应关系即可；而对于输出页面来讲，借助XSL/XSLT的帮助，我们也完全可以抛开Struts的Tag，将XML最终显示成HTML。
3. 从上图中我们可以看到，对于Struts部分在结构上没有任何变化，只是另外加了一个层次。而对于Cocoon来说，虽然看上去我们又多用了一个框架结构，但实际我们不需要对Cocoon做什么程序编写工作，只是需要多维护一个sitemsp.xmap文件（一个XML文件）。

 

但是，任何一种架构或者解决方案都是双刃剑，在我们获得的同时必须有一定的付出。这种模式也带来了如下一些实际的问题。

1. 开发人员需要学习XSL。但我们毕竟需要学习一些东西，相信XSL中对逻辑以及对数据格式等诸多的方便处理给我们的开发人员的项目经理一些学习这些东西的理由；
2. 如何定义我们的数据结构，从而满足我们的业务需求。在自己做过的项目中，经常会遇到一些返回例如用户列表，用XML/XSLT显示报表的具体问题，那么如何能够定义一个比较好的数据结构方便地处理类似的问题呢？
3. 如何使用Cocoon的Pipeline将我们的数据结构转化成XML并最终显示成HTML？经过研究发现，Cocoon提供的Generator无法满足我们具体的数据处理的要求。这个问题我们可以通过扩展Cocoon的Generator来解决。

        回忆以前做的项目，大部分都是Model1，没用EJB的话开发还比较顺利，用了EJB开发起来也挺慢的。Model2只做过一个项目，感觉就一个字“烦”。与Model1最大的变化就是

1.  一个form提交的action不是jsp，而是一个ActionBean；
2. ActionBean得到FormBean之后可以直接从FormBean读取页面提交的参数，而不用每个参 数都request一次。
3. url是.do结尾，而不是xxxx.jsp。