标签：style blog http color java os 使用 文件 数据
以目前自己的理解，所接触到的面向对象思想中最重要的是“抽象”，软件设计目标中最重要的是“可以应对需求的变化（增加或更改）”。
思考一下，无论是“分层”思想，还是“设计模式”思想，还是“泛型”思想等，应该可以说最终的目的都是为了“可以应对需求的变化”，且都充盈着“抽象”。
分层是为了使得“大变小、繁变易”，而针对不同的现实情况，它可以演化出千变万化的原型。分层是一种思想，而Model1、Model2、三层就是分层思想演化出的（经验总结出的）最常用的几种原型而已。它们的真身都是“分层思想”。
下面对以上三种开发模型进行简介：
这种模型是我们初学者最常采用的，因为它建的类文件少，开发比较随意，JSP中既可以写HTML又可以写服务器端代码，所以初学者很青睐这种模型。但这种模型将“业务层”与“表现层”混到了一起，都写到了JSP中，从而使得JSP职责过重。由于“表现”与“业务”两层相混合，所以大大削弱了它的“应对需求变化”能力。这也违背了SUN推出JSP最初的目的。但如果一个项目很小，且需求稳定，就很适合这种架构模型。
上面提到了Model1设计模型中JSP职责过重，违背了SUN最初推出JSP的目的。根据SUN自己的推荐，JSP中应该仅仅存放与“显示层”有关的东西，也就是只放输出HTML网页的部分。而所有的数据计算，数据分析，数据库连接处理等“业务层”的东西都不是JSP的职责。于是Model2模型就解决了这个问题，所有“业务层”相关的东西都放到了Servlet中，JSP就只做渲染页面的单一职能。
Model2模型蕴含了大名鼎鼎的MVC的应用，Model层包含了业务逻辑与持久数据，由普通的java类充当；View层仅作显示，由JSP充当；Controller层取表单数据，整合业务逻辑，转向view页面，由Servlet充当。
Model2在Model1的基础上分离了控制，使得JSP与Servlet各司其职。从而，对比Model1它可以较好地应对需求的变化。这种模型较适合大型项目的开发，因为大型项目需求变更较多，更需要应对需求的增加、修改等。
上面是非常经典的三层架构，从图上可知，它从Model2模型中又抽出了一层“持久化逻辑”。至于原因，很简单，因为Model2模型将“数据访问”与“业务逻辑”混到了一起，这样导致两者之间耦合无法解除，也就意味着，无法对“数据访问”的逻辑进行抽象，所以“数据访问”逻辑的改变（比如更换数据库）必将引起“业务逻辑”的改变，而现实中“数据访问”逻辑又是很容易改变的地方，所以要将其分离，将“数据访问”的职责单独抽到一层“持久化逻辑”中。这样就可以对每个易改变的层进行抽象，从而从依赖于实现转到了依赖于抽象，从而可以更好的应对需求的变化。
层与层之间的依赖关系如下：
每层之间有自上而下地单项依赖关系。划分原则是，将易变化的点抽出来单独做一层，以便于可以对变化点进行抽象，从而从依赖实现转到依赖抽象，从而可以达到“应对需求变化“的目的。它是较正规的一种开发模型。
要知道，想要应对需求变化就要对变化点进行抽象，而想要进行抽象就要先将变化点提取出来（即分层）。
Model1、Model2、三层架构是“分层思想” 结合”经验“所得出的常用的三种设计模型，用以应对现实生活中绝大多数开发场景。分完层我们就可以使用”抽象“的手段，达到”应对需求变化“的目的。
标签：style blog http color java os 使用 文件 数据
原文地址：http://blog.csdn.net/wang379275614/article/details/38834731
