您的位置:首页 > 运维架构 > 网站架构

几种网站开发模型- Model1、Model2、三层

2014-08-26 00:49 323 查看
  以目前自己的理解,所接触到的面向对象思想中最重要的是“抽象”,软件设计目标中最重要的是“可以应对需求的变化(增加或更改)”。

  思考一下,无论是“分层”思想,还是“设计模式”思想,还是“泛型”思想等,应该可以说最终的目的都是为了“可以应对需求的变化”,且都充盈着“抽象”。

  分层是为了使得“大变小、繁变易”,而针对不同的现实情况,它可以演化出千变万化的原型。分层是一种思想,而Model1、Model2、三层就是分层思想演化出的(经验总结出的)最常用的几种原型而已。它们的真身都是“分层思想”。

  下面对以上三种开发模型进行简介:

Model1

  


  这种模型是我们初学者最常采用的,因为它建的类文件少,开发比较随意,JSP中既可以写HTML又可以写服务器端代码,所以初学者很青睐这种模型。但这种模型将“业务层”与“表现层”混到了一起,都写到了JSP中,从而使得JSP职责过重。由于“表现”与“业务”两层相混合,所以大大削弱了它的“应对需求变化”能力。这也违背了SUN推出JSP最初的目的。但如果一个项目很小,且需求稳定,就很适合这种架构模型。

Model2(MVC)

   


上面提到了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、三层架构是“分层思想” 结合”经验“所得出的常用的三种设计模型,用以应对现实生活中绝大多数开发场景。分完层(即将变化点提取出来)我们就可以使用”抽象“的手段,达到”应对需求变化“的目的。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: