Java的开发模型——Model1和Model2……

            最近开发一种用的是Model1模型，也体会到了JSP的职责实在是很大，承担了表现和业务的职责，在感受页面的拥挤的同时也在为能在页面上写java代码和调试java代码而高兴着，也不知道我在高兴什么……

           其实，无论是哪种模型，它的问世应该都是为了解决什么问题的，只是后来的问题又随着出现而又出现了新的解决问题的方法罢了。而这些模型也都有着相同的特点，那就是分层的思想，只是如何分层更能应对变化的结构不同。

            下面是我接触过的三种模型

Model1

            在drp的前一半的代码中，差不多都是Model1模型的，最经典的一句话是：jsp也是一种Servlet，jsp就是Servlet，因为它干的就是Servlet的事嘛！

            Model1呢，看着很简单，在开发中也不过就两个地方需要去敲代码的，一个是逻辑类，一个是jsp。优点就是架构简单、比较适合小型项目的开发，也会提高开发速度。但是我们也看到了，jsp的职责不单一，同时承担了业务和显示的功能，这样的职责过重，不便于维护。如果一个项目很小，开发周期比较短，那么采用这种模型就很适合。如果一个项目非常庞大，那我们就要看是否有其他模型更细致的分层了。

 

Model2

            虽然这个系统现在还没有用Model2来开发，但是对Model2模型还是了解一些的，之前做过的网上商城就是SSH框架的，其实有一部分可以看做是Model2模型的。其实也就是之前我们学过的MVC模型。

            其实，我们可以看到Model1到Model2是逐层划分下来的，在Model1中，是吧显示和业务都放在jsp中了，而演化成Model2的时候，jsp只负责显示，业务调用Servlet来承担，这样的职责就比较单一了，避免了jsp的拥挤和职责过重的情况。Model2也就是解决了这样一个问题。jsp充当了MVC中的V，Servlet充当了C，业务逻辑充当了M。对比Model1，它更好的划分了业务逻辑的层次，让各层各司其职，更好的应对需求的变化。

 

你可知，Model2还可以继续分层下去

            在Model2中，分离了jsp职责过重的困境，但是业务逻辑承担了所有业务逻辑的判断，一些算法、对数据库的操作，返回数据的处理等。相对于前面的两层职责显得也有些重，未免有种下面沉上面轻的现象。如果要是有一个专门对数据库操作的层就好了。

            抽象出来的就是持久化逻辑层，专门负责对数据库的操作，访问数据，我们学过的框架可以承担这一层职责的有Hibernate和EF等ORM的实体关系映射模型。JDBC就是封装了对数据库的各种操作。

            回想之前做过的项目，不管用的是什么框架，都有很好的分层思想，像SSH框架在这个基础上加上的配置文件的控制，也就是Struts和spring的一些配置。不仅是在分层上使职责单一，更是让我们的工作量减少到最低，不用手动去控制转发路径，自动匹配等的思想。具体SSH是怎样的请期待以后的博客。

            在java的学习中，越来越体会到了面向对象、分层、抽象的思想啦~\(≧▽≦)/~啦啦啦……