几种网站开发模型- Model1、Model2、三层
2014-08-26 00:49
323 查看
以目前自己的理解,所接触到的面向对象思想中最重要的是“抽象”,软件设计目标中最重要的是“可以应对需求的变化(增加或更改)”。
思考一下,无论是“分层”思想,还是“设计模式”思想,还是“泛型”思想等,应该可以说最终的目的都是为了“可以应对需求的变化”,且都充盈着“抽象”。
分层是为了使得“大变小、繁变易”,而针对不同的现实情况,它可以演化出千变万化的原型。分层是一种思想,而Model1、Model2、三层就是分层思想演化出的(经验总结出的)最常用的几种原型而已。它们的真身都是“分层思想”。
下面对以上三种开发模型进行简介:
![](http://img.blog.csdn.net/20140826004648312)
这种模型是我们初学者最常采用的,因为它建的类文件少,开发比较随意,JSP中既可以写HTML又可以写服务器端代码,所以初学者很青睐这种模型。但这种模型将“业务层”与“表现层”混到了一起,都写到了JSP中,从而使得JSP职责过重。由于“表现”与“业务”两层相混合,所以大大削弱了它的“应对需求变化”能力。这也违背了SUN推出JSP最初的目的。但如果一个项目很小,且需求稳定,就很适合这种架构模型。
![](http://img.blog.csdn.net/20140826004833181)
上面提到了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它可以较好地应对需求的变化。这种模型较适合大型项目的开发,因为大型项目需求变更较多,更需要应对需求的增加、修改等。
![](http://img.blog.csdn.net/20140826004838812)
上面是非常经典的三层架构,从图上可知,它从Model2模型中又抽出了一层“持久化逻辑”。至于原因,很简单,因为Model2模型将“数据访问”与“业务逻辑”混到了一起,这样导致两者之间耦合无法解除,也就意味着,无法对“数据访问”的逻辑进行抽象,所以“数据访问”逻辑的改变(比如更换数据库)必将引起“业务逻辑”的改变,而现实中“数据访问”逻辑又是很容易改变的地方,所以要将其分离,将“数据访问”的职责单独抽到一层“持久化逻辑”中。这样就可以对每个易改变的层进行抽象,从而从依赖于实现转到了依赖于抽象,从而可以更好的应对需求的变化。
层与层之间的依赖关系如下:
![](http://img.blog.csdn.net/20140826004844616)
每层之间有自上而下地单项依赖关系。划分原则是,将易变化的点抽出来单独做一层,以便于可以对变化点进行抽象,从而从依赖实现转到依赖抽象,从而可以达到“应对需求变化“的目的。它是较正规的一种开发模型。
Model1、Model2、三层架构是“分层思想” 结合”经验“所得出的常用的三种设计模型,用以应对现实生活中绝大多数开发场景。分完层(即将变化点提取出来)我们就可以使用”抽象“的手段,达到”应对需求变化“的目的。
思考一下,无论是“分层”思想,还是“设计模式”思想,还是“泛型”思想等,应该可以说最终的目的都是为了“可以应对需求的变化”,且都充盈着“抽象”。
分层是为了使得“大变小、繁变易”,而针对不同的现实情况,它可以演化出千变万化的原型。分层是一种思想,而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、三层架构是“分层思想” 结合”经验“所得出的常用的三种设计模型,用以应对现实生活中绝大多数开发场景。分完层(即将变化点提取出来)我们就可以使用”抽象“的手段,达到”应对需求变化“的目的。
相关文章推荐
- LINQ快速开发设计最佳实践(二) 构建Model模型
- 软件开发模型(software development model)
- 软件开发常用的几种模型
- 几种软件开发模型
- BalloonShop电子商务网站开发——商品目录(三层架构)(草稿)
- [原创]今天开发第一个三层结构模型的程序。
- 几种软件开发模型
- 符合W3C的网站的开发模型和必要性的探讨(二)
- 符合W3C的网站的开发模型和必要性的探讨(二)
- Asp,PHP,JSP,.Net几种网站开发语言比较
- 软件开发模型(software development model) (转)
- MetaModelEngine:元模型引擎开发思路
- Sharepoint2010应用开发三:使用客户端对象模型(Client Object Model)读取列表数据
- 软件开发过程模型,软件过程模型,软件开发过程几种模型对比
- 符合W3C的网站的开发模型和必要性的探讨(一)
- 软件开发模型(Software Development Model)
- sharepoint2010应用开发一:使用服务端对象模型(Server-Side Object Model)操作列表
- Sharepoint2010应用开发四:使用客户对象模型(Client Object Model)向SharePoint列表写数据
- MOS2010开发基础和集几种开发模型
- asp.net,C#,sqlserver,数据库,iis,js,异常,兼容,搜索,性能,备份,编辑器,存取分离,lucene,SEO优化,产品,运营,MVC,三层架构,nhibernate,microsoft,freamwork,网站开发联盟群号: