JavaWeb程序架构模式的演进

JavaWeb程序架构模式的演进

老一辈的程序员一般都经历了Web程序架构模式的演进,从最开始的在jsp或者jsp+Servlet上做开发,到后来的mvc、三层等。而现在有挺多人学完web,可能都没怎么使用过jsp或jsp+Servlet开发过项目,就直接学习使用Spring、Spring Boot或者SpringMVC等框架进行开发。如果没有经历这样一个逐步演进的过程,就很难理解框架带给了我们什么样的好处,而且开发过程中遇到问题也难以解决,更别说去学习这些框架中的源码了。学习是一个循序渐进的过程,不能急于求成,所以本文旨在简单的聊一聊Web的发展史。

一、web发展简史

以目前Spring Boot作为时间轴的话,web发展的过程大致可以分为以下几个阶段:

1.纯jsp / jsp+Servlet / jsp+JavaBean+Servlet
2.MVC / MVP / 三层架构
3.使用EJB进行分布式应用的开发,EJB是重量级框架,在使用上比较复杂和麻烦
4.由于EJB太重了,于是Spring应运而生,但是Spring在发展上越来越臃肿,所以还是有许多繁琐的配置
5.同样的由于String配置太繁琐,于是Spring boot诞生了,这时就可以体验到 “约定大于配置” 的乐趣

二、web发展初始阶段

1.jsp / jsp+Servlet / jsp+JavaBean+Servlet开发模式:

在最开始的时候,jsp刚刚出来,那时候的web开发基本都是在jsp+JavaBean上完成的。更有甚着直接把页面、逻辑、数据处理全都写在jsp上,想也知道这种方式开发的项目代码不仅乱、而且耦合性相当高,造成项目难以维护。
纯JSP流程图如下:

JSP+JavaBean流程图如下:

相信很多人在刚开始学习JavaWeb的时候,或多或少都使用过以上两种模式的开发,第一种模式就不用说了,所有的代码都写在JSP上耦合度相当地高。第二种模式虽然相较于第一种模式上,在一定程度上解耦了,但JSP依旧要负责页面控制以及请求与响应的处理,职责不单一。耦合度依旧比较高,高度耦合的结果是JSP代码十分复杂混乱,后期维护很困难。

以上这种模式虽然开发起来比较简单,当时这种模式也能够适合一些小型项目的开发,但是由于代码混乱维护困难也就逐渐被淘汰了。

领教到这种模式的蛋疼之后就开始加上了Servlet,这时JSP只负责页面控制,Servlet上负责数据的验证,JavaBean负责具体的业务逻辑与数据处理、封装以及和数据库交互等。

JSP+JavaBean+Servlet流程图如下:

在这种模式上已经开始有点MVC的影子了,但是这种模式还不能称之为一个比较完善的MVC设计模式。这种模式相对于之前的两种模式来说分工更明确,抽取出了Servlet层,体现了一个简单的分层思想。

思维导图:

三、web发展初中级阶段

1.MVC架构模式
这时候web开发上也开始应用了MVC架构模式,尽管MVC早已不是什么新鲜的架构模式了,早在桌面开发的时代MVC模式就已经存在。MVC是Model、View、Controller的缩写,MVC将系统分解为模型、视图、控制器三部分,每一部分都相对独立,职责单一,在实现过程中可以专注于自身的核心逻辑。MVC是对系统复杂性的一种合理的梳理与切分,它的思想实质就是“关注点分离”。至于MVC三元素的职责划分与相互关系,这里不再赘述,下图给出了非常细致的说明:

上图说明了MVC组件的功能和关系。

MVC模式各部分之间的通信方式如下:

View 传送指令到 Controller
Controller 完成业务逻辑后,要求 Model 改变状态
Model 将新的数据发送到 View,用户得到反馈
所有通信都是单向的

接受用户指令时,MVC 可以分成两种方式。一种是通过 View 接受指令,传递给 Controller,流程图如下:

另一种是直接通过controller接受指令,流程图如下:

一般在实际项目中往往采用更灵活的方式,通常会把这两种方式结合在一起,大致流程图如下:

1.用户可以向 View 发送指令(页面请求)。
2.用户也可以直接向 Controller 发送指令(Servlet请求)。

现在的SpringMVC就是MVC架构模式的框架。

MVP架构模式:
MVP与MVC很像,MVP 是从经典的模式MVC演变而来,它们的基本思想有相通的地方:Controller/Presenter负责逻辑的处理,Model提供数据,View负责显示。所以很多人都不是很分的清这两种模式的区别,简单来说两者主要的区别在于,MVC是单向通信的,而MVP是双向通信的。MVP模式将 Controller 改名为 Presenter,所以同时改变了通信方向,流程图如下:

MVP特点:

  • 各部分之间的通信,都是双向的。
  • View 与 Model 不发生联系,都通过 Presenter 传递。
  • View 非常薄,不部署任何业务逻辑,称为"被动视图"(Passive View),即没有任何主动性,而 Presenter非常厚,大部分主要逻辑都部署在那里。

三层架构模式:
三层架构(3-tier architecture) 通常意义上的三层架构就是将整个业务应用划分为:界面层(User Interface layer)、业务逻辑层(Business Logic Layer)、数据访问层(Data access layer)。区分层次的目的即为了“高内聚低耦合”的思想。在软件体系架构设计中,分层式结构是最常见,也是最重要的一种结构。微软推荐的分层式结构一般分为三层,从下至上分别为:数据访问层、业务逻辑层(又或称为领域层)、表示层。

很多人容易把三层模式与MVC模式混淆,三层与MVC的最不同的地方在于三层是没有Controller控制器的概念。虽然同样是架构级别的,三层与MVC相同的地方在于他们都有一个表现层,但是他们不同的地方在于其他的两个层。MVC没有把业务的逻辑访问看成两个层,这是采用三层架构或MVC搭建程序最主要的区别。当然了,在三层中也提到了Model概念,但是三层架构中Model的概念与MVC中Model的概念是不一样的,“三层”中典型的Model层是以实体类构成的,而MVC里,则是由业务逻辑与访问数据组成的。

在三层中JSP与Servlet代码都属于表示层,业务逻辑层则是完成业务规则的实体类,数据访问层则是JDBC等代码,示意图:

以上已经介绍了几种架构模式,可以看到架构模式的演进目的都是为了解耦,低耦合的架构才能方便于项目后期的维护和扩展,好的架构模式才能让项目有较好的健壮性。

四、web发展中高级阶段

这个阶段开始使用EJB进行分布式应用的开发:

EJB是sun的JavaEE服务器端组件模型,设计目标与核心应用是部署分布式应用程序。简单来说就是把已经编写好的程序(即:类)打包放在服务器上执行。凭借java跨平台的优势,用EJB技术部署的分布式系统可以不限于特定的平台。EJB (Enterprise JavaBean)是J2EE(javaEE)的一部分,定义了一个用于开发基于组件的企业多重应用程序的标准。其特点包括网络服务支持和核心开发工具(SDK)。 在J2EE里,Enterprise Java Beans(EJB)称为Java 企业Bean,是Java的核心代码,分别是会话Bean(Session Bean),实体Bean(Entity Bean)和消息驱动Bean(MessageDriven Bean)。在EJB3.0推出以后,实体Bean被单独分了出来,形成了新的规范JPA。

EJB 从技术上而言不是一种"产品",EJB 是一种描述了构建应用组件要解决的标准:

  • 可扩展 (Scalable)
  • 分布式 (Distributed)
  • 事务处理(Transactional)
  • 数据存储(Persistent)
  • 安全性 (Secure)

以上转自百度百科。

由于我个人没有使用过EJB进行开发,不敢随便发表意见,以免误导大家,对EJB有兴趣的可以参考以下文章:

http://www.uml.org.cn/j2ee/2009112011.asp

Spring的诞生:
Rod Johnson在2002年编写的《Expert One-to-One J2EE Design and Development》一书,Rod 在本书中对J2EE正统框架(EJB)臃肿、低效、脱离现实的种种学院派做法提出了质疑,并以此书为指导思想,编写了interface21框架,也就是后来的Spring。

基于最优方法并适用于各种应用类型的Spring框架的建立要归功于Rod Johnson。这些想法也在他的书中得以阐述。书发表后,基于读者的要求,源代码在开源使用协议下得以提供。

一批自愿拓展Spring框架的程序开发员组成了团队,2003年2月在Sourceforge上构建了一个项目。在Spring框架上工作了一年之后,这个团队在2004年3月发布了第一个版本(1.0)。这个版本之后,Spring框架在Java社区里变得异常流行,部分的要归结于它好于一般水准的文档功能和参考文献,特别是对于一个开源项目而言尤其如此。

Spring解决的是业务逻辑层和其他各层的松耦合问题,因此它将面向接口的编程思想贯穿整个系统应用。简单来说,Spring是一个分层的JavaSE/EEfull-stack(一站式) 轻量级开源框架。

Spring框架的特征:

  • 轻量
  • 控制反转
  • 面向切面
  • 容器
  • 框架
  • MVC

Spring架构概述:

Spring虽然相较于EJB要轻量很多,但是发展到现在,Spring也有些臃肿了,在配置上也稍微有些繁琐,但是Spring依旧是现在的主流框架之一。框架的存在就是为了方便于我们使用一些架构模式,不必再从底层去开始开发,提高了开发的效率。

五、web发展目前阶段

到目前为止,已经出现了很多优秀的java开源框架,常见的有Spring、SpringMVC、Spring Boot、Struts 、Hibernate、MyBatis等,其中Spring Boot是Spring框架的简化。通过这些框架,我们可以很高效的应用架构模式去开发大型的项目。

化繁为简,Spring Boot框架:

Spring Boot是由Pivotal团队提供的全新框架,其设计目的是用来简化新Spring应用的初始搭建以及开发过程。该框架使用了特定的方式来进行配置,从而使开发人员不再需要定义样板化的配置。通过这种方式,Spring Boot致力于在蓬勃发展的快速应用开发领域(rapid application development)成为领导者。

Spring Boot特点:

  • 可以创建独立的Spring应用程序
  • 嵌入的Tomcat,无需部署WAR文件
  • 简化Maven配置
  • 自动配置Spring
  • 提供生产就绪型功能,如指标,健康检查和外部配置
  • 绝对没有代码生成以及不要求配置XML

Spring Boot虽然目的是为了简化Spring,似乎看起来无需去学习Spring的繁琐配置,直接学Spring Boot多好啊,配置简单美滋滋,但是如果没有忍受过Spring的繁琐配置,没有经历过架构模式的演进以及JavaWeb基础不扎实的话,在使用Spring Boot的过程中就容易出现没有遇到过的错误,也不知道如何去解决。而且设计模式不熟悉的话,也不知道人家框架是怎么进行实现的,设计思想完全不知道,那么即便有好的框架在手也没法玩得6,更别说去设计架构模式了。

六、小结

从以上的演进简史可以看到目前这些主流框架是怎么来的,为什么要有这些框架。可以说我们目前学习技术的时代赶上了最好的时代,现在有那么多优秀的开源框架可以使用,又有那么多的设计思想可以借鉴,我们跳过了很多前人经常踩的坑,正是前人踩过了这些坑之后,才能发展那么多优秀的开源框架与设计思想。但是我们也应该要去经历一下这种架构模式的演进,才能深刻体会到不同的架构模式与框架带给我们的好处。现在的新东西越来越多,你我只有不停的进步,不停地学习才能跟上这个时代。

原文地址:http://blog.51cto.com/zero01/2062619

时间: 2024-07-30 10:54:38

JavaWeb程序架构模式的演进的相关文章

大型JavaScript应用程序架构模式

11月中旬在伦敦举行的jQuery Summit顶级大会上有个session讲的是大型JavaScript应用程序架构,看完PPT以后觉得甚是不错,于是整理一下发给大家共勉. PDF版的PPT下载地址:http://www.slideshare.net/jibyjohnc/jqquerysummit-largescale-javascript-application-architecture 注:在整理的过程中,发现作者有些思想是返来复去地说,所以删减了一部分,如果你的英文良好,请直接阅读英文的

转: GUI应用程序架构的十年变迁:MVC,MVP,MVVM,Unidirectional,Clean

十年前,Martin Fowler撰写了 GUI Architectures 一文,至今被奉为经典.本文所谈的所谓架构二字,核心即是对于对于富客户端的 代码组织/职责划分 .纵览这十年内的架构模式变迁,大概可以分为MV*与Unidirectional两大类,而Clean Architecture则是以严格的层次划分独辟蹊径.从笔者的认知来看,从MVC到MVP的变迁完成了对于View与Model的解耦合,改进了职责分配与可测试性.而从MVP到MVVM,添加了View与ViewModel之间的数据绑

Hibernate(1)——数据访问层的架构模式<转>

数据库的概念.逻辑.数据模型概念 应用程序的分层体系结构发展 MVC设计模式与四层结构的对应关系 持久层的设计目标 数据映射器架构模式 JDBC的缺点 Hibernate简介 迅速使用Hibernate开发的例子 Hibernate的核心类和接口,以及他们的关系 POJO和JavaBean的比较 之前的一篇总结文章: 数据库精华知识点总结(1)—数据库的三层模式和二级映像,E-R(实体联系图)图,关系模型 简单来说,就是在软件开发领域,可以用模型表示真实世界的实体.针对数据库就分为: 概念模型(

云开发初探 —— 更简便的小程序开发模式

欢迎大家前往腾讯云+社区,获取更多腾讯海量技术实践干货哦~ 本文由李成熙heyli发表于云+社区专栏 李成熙,腾讯云高级工程师.2014年度毕业加入腾讯AlloyTeam,先后负责过QQ群.花样直播.腾讯文档等项目.2018年加入腾讯云云开发团队.专注于性能优化.工程化和小程序服务. 小程序诞生以来,业界关注小程序前端的技术演进较多,因此众多小程序前端的框架.工具也应运而生,前端开发效率大大提高,而后台的开发技术则关注不多,痛点不少,具体痛在哪里呢? 小程序后台开发之痛 第一个是脑袋瓜疼,怎么疼

云原生应用程序架构的五大特性(上)- 12要素应用

12要素的概念最早诞生于Heroku的工程师手中,说白了,其实就是云原生应用程序架构的模式集合,它描述了一个应用程序的原型,最好地诠释了采纳云原生应用程序架构的原因. 通过突出陈述性配置和水平扩展的无状态/无共享进程,以及整体上与部署环境的松耦合连接,这些模式实现了速度性.安全性和可扩展性.在当下,Cloud Foundry.Heroku和Amazon Elastic Beanstalk等云应用程序平台都已经为部署12要素应用进行了优化. 12要素视应用程序为可独立部署的单元,企业通常将多个可协

饿了么的架构设计及演进之路

网站在刚开始的时候大概只是一个想法:一个产业的模型,快速地将它产生出来."快"是第一位的,不需要花太多精力在架构设计上.在网站进入扩张期才需要对架构投入更多的精力来承载网站在爆发时的流量. 饿了么成立已经8年,现在日订单量突破900万,我们也有了较为完善的网站架构.   一.网站基础架构 初期,我们使用了能够更容易拓展SOA的框架.我们用SOA的框架解决两件事情: 1. 分工协作 网站初期,程序员可能就1~5个,那时大家忙同一个事情就可以了.彼此之间的工作都互相了解,往往是通过&quo

分层与架构模式

1 企业应用计算的演变 这个我们应该是在学HTML的时候就已经学习了一部分了,现在再来回忆一些理论知识! •主机/哑终端的集中计算模式 大型主机管理和控制应用程序的所有方面,包括业务处理.数据管理和屏幕显示.使用者一般通过只有一个屏幕.一个键盘和一根主机连接线的“哑终端”与主机的应用程序进行交互. 缺点: 一台计算机中进行全部的处理. 应用程序非常难于维护. 专用特性使得它们非常难于集成其他平台上的其他应用程序 •客户机/服务器计算模式 –分布式客户/服务器 (Client/Server,简称C

《大型网站技术架构》读书笔记二:大型网站架构模式

一.分层 最常见的架构模式,将系统在横向维度上切分成几个部分,每个部分单一职责.网站一般分为三个层次:应用层.服务层和数据层,其具体结构如下图所示: 通过分层,一个庞大系统切分成不同部分,便于分工合作和维护. 但是,分层架构也有一些挑战:①必须合理规划层次边界和接口:②禁止跨层次的调用及逆向调用. 二.分割 分割是在纵向方面对软件进行切分->将不同的功能和服务分割开来,包装成高内聚低耦合的模块单元,有助于软件开发和维护,还便于不同模块的分布式部署,提高网站的并发处理能力和功能扩展能力. 三.分布

MVC架构模式

MVC架构模式 参考: MVC框架_百度百科https://baike.baidu.com/item/MVC%E6%A1%86%E6%9E%B6/9241230?fr=aladdin MVC框架 MVC全名是Model View Controller,是模型(model)-视图(view)-控制器(controller)的缩写,一种软件设计典范,用一种业务逻辑.数据.界面显示分离的方法组织代码,将业务逻辑聚集到一个部件里面,在改进和个性化定制界面及用户交互的同时,不需要重新编写业务逻辑.MVC被