多角度看Model1与Model2

Model1与Model2就是jsp+javabean和jsp+servlet+javabean两种模式，前者属于纯jsp开发，后者是简单的MVC。它们是sun公司先后提出的两种MVC模式的规范。

概念介绍：

Model1，分为视图层与模型层。jsp充当了很重的角色：负责页面显示、调用模型处理业务逻辑、控制页面跳转。模型层就是javabean，负责处理业务逻辑。

Model2，也就是MVC设计模式，是基于Model1的进一步改进。从Model1中的视图层中分理出控制，也就是Model2的模式.MVC分为M、V、C三层。

M（Model）模型，就是javabean，主要职责就是处理业务逻辑；

V（View）视图，主要负责页面显示；

C（Controller）控制，负责取得表单数据、调用业务逻辑、转发或重定向到页面。

架构分析：

在Model1中，jsp负责的职责太重，并且将显示、部分逻辑与控制耦合在一起，不利于大型开发与后期的系统维护。同时jsp页面里面既有html标签，也有java代码。这无形中就对程序员提高了要求。美工处理页面时，时不时看见一下java代码，显得不伦不类；而编写java代码的需要看大量的html标签，不利于合作开发。

Model2将控制（Servlet）从jsp页面中分离出来，jsp做的只是页面渲染，通过使用JSTL标签，可以将动态的信息以标签的形式显示在页面上。这样，jsp的职责就单一了，只负责页面显示，便与合作开发，分工合作。

而控制层的Servlet去进行逻辑调用、控制页面转向。

Model1和Model2都有模型层。模型层主要是javabean，进行业务逻辑处理，这里的业务逻辑包括具体的业务再现和持久化逻辑。这里可以对Model进行细化：将持久化逻辑独立出来，也就是三层架构的思想；可以再建立接口层，实现都依赖于抽象，而不依赖于具体实现，也就是工厂或者抽象工厂+反射。

谈到分层划分，这里又涉及到一个粒度划分的问题：Model层中的Manager逻辑是与dao层对应还是与页面对应。如果页面逻辑简单的话，就没有这个问题了，因为他都是对应的；如果页面逻辑比较负责，下面举个例子：

现在dao层有物料管理和流向单管理两个dao部分。假如Manager层中如果与dao层对应，那么就应该有两个Manager，即物料管理Manager和流向单管理Manger两部分，如果页面需要这两部分的信息，在一个控制里面，就需要调用这两个Manager；

假如Manager与页面逻辑相对应，那么在控制里面只需要调用一个某某Manager就可以了。而在这个Manager中就会调用dao层的两部分逻辑。

个人认为，比较好的设计，是两种设计的结合。dao层也加入简单的业务逻辑，不过粒度需要掌握，业务逻辑越多，通用性越差；Manger层也不应该与dao层完全一一对应，假如dao层现在又有流向单详细信息管理，那么流向单的Manager只需一个方法与之对应即可。也就是说这个方法中包含了流向单信息和流向单详细信息两部分信息。

另外，我还有一个疑问：一个控制频繁调用多个Manager是否合适？

多个Manager的组合调用，是复用的体现；然后多个Manager的组合，本来就是业务逻辑，控制中涉及太多的业务逻辑，总感觉不太好。此中取舍，在项目中实践吧。

从jsp和Servlet角度分析：

一个Servlet就是一个Java类，它被用来扩展服务器的性能，服务器驻留着可以通过“请求-响应”编程模型来访问的应用程序。虽然Servlet可以对任何类型的请求产生响应，但通常只用来扩展Web服务器的应用程序。Java Servlet技术为这些应用程序定义了一个特定的HTTP的Servlet类。

那jsp呢？jsp就是Servlet。jsp也是在服务器运行的，每一个jsp都会在tomcat容器下相应路径里生成对应的Servlet，在这个Servlet里面，会将jsp页面上的静态内容和动态内容分别打印出来。每一次用户请求，tomcat都会将页面重新发送回浏览器。

既然jsp就是Servlet，那么还有必要引入MVC，进行分离控制吗？

答案无疑是肯定的，分离控制有莫大的好处。jsp虽然在服务器执行，但是里面可以全部是便签，美工人员完全可以看懂。即便是不懂jsp的人员，能看懂html标签，培训两天就能够进行开发。而控制层的Servlet全是Java代码，实现了显示逻辑与控制逻辑的分离。同时，分离控制，彼此之间职责明晰，有利于分工合作，便于后期维护。

从需求角度分析：

需求就意味着变化，我认为“活软件”主要包括两方面：

1、用户用着顺手，容错性好；

2、程序设计灵活，便于修改。

对于Model1来说，开发费用会小一些，但面临需求变更，业务修改，显然非常乏力；而Model2能够较好的面对需求变化。不过面对大量的需求变动，我们可以基于Model2，进行进一步的分层设计，层与层之间依赖抽象，而不依赖于具体实现。需求变更时，做到改动最小化，费用最小化。

总结：

个人认为：Model1已经不能适应社会的发展了，而我们的开发也会将在Model2的基础上进行扩展，做出更加灵活，更加利于修改的设计。