曾经做的就是按照思维做的三级制,这是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中使用了“工厂模式”,封装创建过程。
在持久层的设计中有几个重要的原则:细粒度————细粒度的目的是为了达到高复用性。
:要单纯————不涉及或者非常少有过多的业务逻辑。
一步一步进化的模型,就是一种思想的演变。有一种思想非常重要。行动上要懒惰,思想上要积极。为了自己能够在行动上懒惰,而发动思维运动,这就是“代码复用”。
版权声明:本文博主原创文章,博客,未经同意不得转载。