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