曾经做的就是按照思维做的三级制，这是U 。B ，D 。坐在坐，开始增加设计模式，增加sqlhelper ，逐渐了解系统可分为只三层，层的，随着学习的不断深入明确了“为什么会出现分层”。知道了是一回事，关键还是在“怎么用”，所以我们还在为“分层”而进行不懈的努力着……
如今学习到了DRP。又认识了一个分层：MVC（model-view-control）。
正式语言这么描写叙述：用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同一时候。不须要又一次编写业务逻辑。对于有系统经验的朋友们，对这些描写叙述是深有感悟。
以下我们来简单看一下这个模型的始末。
一、MVC 的前身
一个非常easy的调用，从前端到JSP到业务逻辑。
图中能够看出它的长处：结构简单，easy操作。
再看第二眼：锁定JSP 。1、取得页面參数，
2、调用业务逻辑。
3、到返回数据
4、渲染页面
5、将渲染结果response 给前端页面
假设要给JSP职责分类的话，1~3，是一致的。那么4 （渲染页面）就显得格格不入，由于，我们有前端，这个JSP既有“业务逻辑处理”，又有“页面处理”，这在三层中。该属于U,B 混搭了。
所以他的缺点就是： 职责不单一，责任过重，不便于维护。可是这个适合小型项目的开发。
不论什么分层思想都是一样的，就是为了“职责单一。便于管理”，这里既然分层不彻底。那么就又一次分呗。有了MVC。
二、MVC
这个图就攻克了“混搭”的问题，相对于刚才那个，这个模型适合大型项目开发。
通过引入Servlet 来分担JSP中调用“业务逻辑”的功能。让JSP 仅仅做“渲染页面”来实现页面和业务逻辑的排排站。
这里做到了前端和业务逻辑的分离，可是之前我们说了，一个系统不止有“x”层，我们所熟知的“层”。是通用的写好的一种规范，在实际中，我们能够依据业务须要在“已知层”上进行抽象。包装属于“系统”的层。
接下来要说的仅仅是在MVC的基础上加一个“数据訪问”的层。当然。这个不属于某一个系统独有。基本全部的系统都会涉及到数据库的訪问，和数据库连接的驱动分，方法等基本都是一致的。所以能够封装成一层，作为“持久层”。
一般持久层的使用都会和DAO配合，在DAO中使用了“工厂模式”，封装创建过程。
在持久层的设计中有几个重要的原则：细粒度————细粒度的目的是为了达到高复用性。
：要单纯————不涉及或者非常少有过多的业务逻辑。
一步一步进化的模型，就是一种思想的演变。有一种思想非常重要。行动上要懒惰，思想上要积极。为了自己能够在行动上懒惰，而发动思维运动，这就是“代码复用”。
版权声明：本文博主原创文章，博客，未经同意不得转载。