(第一章更新完成) 17.3.29
Java EE设计模式 Spring企业级开发最佳实践
@(java读书笔记)
文章目录
Pro Java EE Spring Patterns
Best Practices and Design Strategies Implementing Java EE Pattern with the Spring Framework
[印] Dhrubojyoti Kayal 著
张平 龚波 李平芳 等译
概要总结
from 前言和序言
本书内容(这本书在讲什么?)
本书将Java EE设计模式和Spring框架融合在了一起。
本书致力于归纳在Spring框架中常用的设计策略(符合Java EE 5规范)
本书结合Spring框架讲解了Java EE设计模式,主要介绍了Java EE应用程序设计和Spring框架的基础知识,描述了表现层、业务层和集成层中使用的设计模式,提供了每个模式的实现细节并分析了其优缺点,最后运用书中所讲的内容示范了开发订单管理系统的过程。
读书目标(为什么要看这本书?)
细读本书,你能了解企业级Java/Java EE 应用程序设计模式,学习使用流行的Spring框架来简化企业Java设计,掌握表现层、业务层和集成层的设计模式和最佳实践,包括横切设计模式、AOP等。
本书对象(哪些人适合看这本书?)
本书主要适合Java EE应用程序设计人员和架构师使用,也非常适合熟悉Java EE设计模式和Spring框架的开发人员使用。
预备知识(看懂这本书的前提?)
本书假设读者熟悉Java EE 设计模式、Spring框架以及Eclipse IDE。
第1章 企业级Java应用程序架构和设计简介
本章内容:
简要介绍了Java EE应用程序架构和设计的基本内容,它们是整个应用程序的开发基石。
为什么Java EE能成为各行业开发和部署企业级业务应用程序的首选平台?
这是由于Java EE提供了一个基于标准的平台,可用来构建强壮和高扩展性的分布式应用程序,以支持从银行核心业务到航空订票引擎在内的所有业务。
使用Java EE开发的重要条件是什么?
由于Java EE 平台提供的丰富选项大的惊人,数量繁多的框架、实用工具库、IDE以及各种工具,使得开发工作更具有挑战性,因此选择合适的技术是至关重要的。选择具有良好架构和设计的技术,才有可能构建易于维护、复用和扩展的应用程序。
1.1 分布式计算的发展历程
在分布式计算中,应用程序被分割成同时在多台计算机上运行的若干个小应用程序。这些小应用程序也被称作层(tier)。每个tier都提供可供连接层或者客户层使用的独立的服务集合,这些tier可以进一步划分为多个规模更小的层(layer),以提供更精细的功能。
现阶段大多数应用程序都有三个layer:
- 表现层(Presentation Layer):用来处理用户界面相关处理操作。
- 业务层(Business Layer):负责执行业务规则。
- 数据访问层(Data Access Layer):负责检索和处理存储在企业信息系统(EIS)中的数据。
1.1.1 单层架构(single-tier architecture)
可追溯到哑终端的独立主机时代
即终端只具备非常有限的文本处理能力,整个应用程序都被部署在同一台物理主机上。
1.1.2 两层架构
20世纪80年代初期,PC开始流行后。
PC处理能力逐渐强大,为client-server计算提供了基础。有两种CS结构:
- GUI应用程序与服务器交互,服务器执行业务逻辑和数据访问,客户端负责执行数据验证。
- 第二种是客户端负责数据验证和业务逻辑处理,服务器仅是个数据库服务器,这种也被称做胖客户端
1.1.3 三层架构
20世纪90年代中期,硬件成本急剧下降,CPU处理能力急剧提升,快速成才的Internet以及发展迅猛的基于Web的应用程序开发,催生了三层架构。
客户端PC部署瘦客户端软件,如浏览器,以显示从服务器所返回的数据内容,服务器驻留表现逻辑、业务逻辑和数据访问逻辑。数据来源于EIS,如关系型数据库。
由于整个应用程序都部署在服务器上,所以这种服务器也被称作应用程序服务器(application server)或者中间件(middleware)。
1.1.4 多层架构
随着Internet带宽的快速增长,世界各地企业都提供基于Web的服务。
应用程序服务器不再负责处理表现层的任务,这项工作由专门的Web服务器处理,由它生成需要显示的内容,传递给客户端的浏览器,浏览器负责显示用户界面。多层架构的应用程序服务器上驻留可远程访问的业务组件,以及访问数据的数据访问组件。
1.1.5 Java EE架构
1999年,Sun公司发布Java EE2平台,以解决分布式多层企业级应用程序开发过程存在的问题。
该平台基于J2SE开发,有利于实现应用程序“一次编写,即可到处部署并运行”的目标。
由于它是基于规范的,所以从开源社区到主要的商用软件提供商,都支持这个平台。所有人都可以在其上面开发服务,只要它符合相关规范。
那么,分布式多层企业级应用程序开发过程存在哪些问题?
-
开发多层架构的分布式应用程序,是一项非常复杂、极具挑战性的工作。人们一般将任务分摊多个层,为合适的专家分配他擅长实现和开发特定层的任务,如:网页设计者更适合处理表现层,数据库开发者则可几种开发存储过程和函数。但是这些层相互孤立是没有任何价值的,需要将它们集中起来才能实现更大的企业级目标,如果没有充分利用最有效的协议,这样的集成工作会导致性能急剧下降。
-
分布式应用程序还需要各种各样的服务,在和不同的信息系统交互时,这些服务必须能够创建、参与或者管理事务,只有这样才能保证并发处理企业数据,由于是通过Internet访问多层应用程序,所以必须有功能强大的安全服务支持,阻止对应用程序的恶意访问。
-
硬件成本虽极具下降,但仍存在一些限制,有必要优化使用系统资源,如处理器支持的最大存储器容量有限。当前的分布式应用程序通常使用面向对象技术,因此对象缓存或对象池之类的服务是非常方便的,这些应用程序经常会与关系型数据库或者其他信息系统(如面向消息的中间件)进行交互,与这些系统简历连接的成本是非常大的,需要耗费大量的处理资源,导致应用程序性能严重下降,这种情况下,连接池就显得特别有用,它不仅可以改进引用程序性能,还能优化资源利用。
-
分布式应用程序通常使用中间件服务器来利用系统服务,如:事务、安全和缓冲池。由于必须使用中间件服务器API才能访问这些服务,所以应用程序代码中会充满专用的API代码,这样的话,除了带来可移植性方面的限制外,还会花费大量的开发时间,并且导致应用程序未来难以维护。
1. Java EE 容器架构
Java EE平台通过基于容器的架构来提供必须的系统服务。容器为用Java编写的面向对象的应用程序组件提供了运行时环境。它提供底层服务,如安全、事务、生命周期管理、对象查询和缓存、持久化以及网络通信等。这样的话,就可以清楚的分离这些功能。系统程序员可以专注于开发底层服务,而应用程序员则更专注于开发业务逻辑和表现逻辑。
有两个服务器端容器:
- Web容器驻留表现层组件,如JSP和servlet,这些组件也使用远程协议和EJB容器进行交互
- EJB容器管理EJB组件的运行
EJB容器和Web容器共同行程了JavaEE应用程序服务器,这个服务器驻留在Java虚拟机中。
在客户端,应用程序客户端是核心的Java应用程序,通过网络链接到EJB容器,另一方面,Web浏览器通常使用Http协议和Web容器进行交互。
不同的容器提供不同的底层服务集。如Web容器不提供事务支持,但EJB容器提供。
2. Java EE 应用程序架构
MVC
mvc将一个应用程序划分为3个不同的但又相互协作的组件:
- 模型(model)通过应用业务规则来管理应用程序的数据;
- 视图(view)负责显示应用程序的数据,并允许用户和系统进一步交互;
- 控制器(controller)负责协调模型和视图。
[外链图片转存中…(img-SW94Vgos-1727430488049)]
任何用户动作所触发的事件都会被控制器截获。
根据用户动作,控制器会调用模型,以应用能够该应用程序数据的相应业务规则。
控制器会选择视图组件,向最终用户显示修改后的应用程序数据
使用MVC所提供的原则,可以非常清晰地分离应用程序中不同的功能/组件。正是由于这种分离,才允许在同一模型中使用多个视图和控制器。
在Java EE 架构中使用MVC
[外链图片转存中…(img-WVkMhubb-1727430488049)]
运用MVC的设计理念很容易形成Java EE 应用程序架构的基础:
Java EE servlet技术特别适合用作控制器组件。任何浏览器请求都可通过HTTP协议传递到servlet。
然后,servlet控制器会调用EJB模型组件,该组件封装了相应的业务规则,并会检索和修改应用程序数据。
使用JSP,可以显示被检索和修改的企业数据。
以上也是一个现实企业Java架构相当简化的表述方式。
Java EE 应用程序的层
Java EE的分层架构,其实就是对MVC架构的一种扩展。
在传统MVC架构中,数据访问层或者集成层都被视为业务层的一部分,Java EE中将它声明为一个独立的层。因为企业级的Java应用程序访问的数据库系统多种多样,且非常频繁,独立后,可以使业务层更集中处理它的核心功能——执行业务规则。
1.2 Java EE 应用程序设计
1. 使用模式简化应用程序设计
设计模式描述常见设计问题的可复用解决方案。它们是那些富有经验的开发人员和设计人员经过反复验证而总结的指南和最佳实践。模式主要有以下3个特征:
- 上下文是问题存在的相关条件。
- 问题是域中复杂而不确定的主题。它受限于当前上下文。
- 解决方案是解决问题的方法
但是只有经常出现的问题的可复用解决方案才能被视为模式。
模式还必须建立公用的术语表,以方便与开发和设计人员交流。
为实现设计模式,通常还需要和代码段一样,辅以结构性和交互性图表来加以描述。
最后,描述每种模式时通常都要进行优点和相关影响分析。
1.3 Java EE 设计模式目录
一些软件产品之所以会失败,主要有几个原因,其中最为重要的一个原因就是设计和架构工作做的不够。这是一个绝对关键的原因,因为设计和架构是需求阶段到构造阶段的桥梁。
Java EE模式目录为Java EE应用程序的每个层中对象之间的交互提供了久经考验的解决方案的知道方针和最佳实践。
上表到目前应该有少许变动,而且也不够完善,有些模式可在多个层上使用,比如安全设计模式可在表现层中使用,以限制对Web资源(比如JSP)的访问。同样,安全模式也可用来控制业务层EJB组件的方法调用。又比如,事务模式既可以用于业务层,又可以用于集成层。本章把这些模式(可以在多个层上使用的模式)归为横切(cross-cutting)模式。
1.4 使用 UML 描述 Java EE 架构设计
大多数系统都是迭代开发的,随着需求的稳步增长,应用系统也变得越来越庞大。此类系统的核心是通过迭代形成的高级别的设计和架构。
同样重要的是,设计和架构都使用文本和可视化表格的形式给出说明,以供开发和后期维护人员参考。
这些可视的表示方法非常实用,因为它们有助于开发人员了解运行时的交互和编译时的依赖关系。
UML是一种适合对复杂企业系统的架构和详细设计进行建模的可视化展示的图形化语言。
UML不拘泥于架构和设计,可应用到软件开发的各个阶段。
UML提供了一套完整的描述符,可以描述类、对象以及它们之间的关系和交互。
一些UML建模工具包括:IBM Rational XDE、Visual Paradigm和Sparx Systems Enterprise Architect等允许在系统设计期间使用设计模式和最佳实践,借助这些工具可以基于设计模式生成很大一部分的应用程序源代码。
1.4.1 类图
类图可用于描述系统中一组类和接口之间存在的静态关系。
1. 泛化(generalization)关系
泛化关系表示两个或者更多类之间的继承关系。这是一种父 - 子关系。如下图:
2. 关联关系
关联关系描述两个类之间的关系。这种关系可用来表示某个类包含其他类的实例。
3. 聚合(aggregation)关系
聚合关系是一种特定形式的关联,其中一个元素由多个更小的元素组成。聚合关系使用空心菱形表示。在聚合关系中,如果删除了父对象,子对象仍可能继续存在。
[外链图片转存中…(img-cWSJ1rBX-1727430488050)]
3. 组合关系
组合是一种更强形式的聚合。在这种情况下,如果删除了父对象,那么子对象也将不复存在。这种关系一般通过实心菱形表示。
[外链图片转存中…(img-dLtH4PtB-1727430488051)]
1.4.2 序列图
序列图一般通过描述系统某段时间内,对象之间的消息交换序列,来模拟系统的动态行为。
序列图通常用来展示系统中对象为满足特定的用例相互之间所发生交互活动的序列。
类图可以用来表示整个应用程序的域模型,序列图只能显示特定处理过程的交互细节。
1. 对象和消息
在序列图中,使用包含带下划线文本的矩形框来表示对象。
用始于摸个对象而止于另一个对象或自己的实线箭头来表示消息。
2. 生命线
生命线是对象之间进行消息交换的时间轴,用垂直于对象框的虚线来表示。
如下图:
3. 返回值
消息的返回值是可选的,如下图,消息createNewPolicy返回了一个PolicyDetail对象。
1.5 小结
分布式多层应用程序的开发是一项十分艰巨的任务。在Java EE平台上,通过定义一个基于容器的架构,可以简化此项任务。它为应用程序代码和低级系统服务定义了运行时环境规范,从而允许应用程序开发人员将精力集中在业务逻辑实现上。Java EE应用程序架构基于核心的平台架构和MVC原理。正是出于这个原因,开发人员可在每个层上清晰地定义专用的组件层。比如,Web层驻留应用稈序的表现层,而业务层和数据访问层一般驻留在应用程序服务器层。
从另一方面来说,Java EE设计是一种扩展的对象设计。Java EE设计模式提供了构造对象以及在不同层对象间交互的指南和最佳实践。这些设计模式记录了设计和开发人员多年来曾经交付Java EE应用程序的成功经验。可以使用UML表示法来表示Java EE设计和架构。UML以图形化方式向用户展示域对象的静态架构和动态交互行为。
下一章将介绍Spring框架是如何进一步简化Java EE应用程序设计和架构的。如果读者己经非常熟悉Spring框架,可直接阅读第3章的内容。