1.1 Java EE应用概述
1.1.1 Java EE应用的分层模型
不管是经典的Java EE
架构,还是本书介绍的轻量级Java EE
架构,大致上都可分为如下几层:
领域对象层
领域对象层由一系列的POJO
组成,POJO
是Plain Old Java Object
的缩写,也就是普通的、传统的Java
对象,这些传统的Java
对象是该系统的领域对象,领域对象
往往包含了
各自所需实现的业务逻辑方法
。
DAO层
DAO
是DataAccessObject
的缩写,所以DAO
层也叫数据访问对象层。DAO
层由一系列的DAO
组件组成,这些DAO
实现了对数据库的创建、查询、更新和删除(CRUD
)等原子操作。
注意
在经典JavaEE
应用中,DAO
层也被称为EAO
层,EAO
层组件的作用与DAO
层组件的作用基本相似。只是EAO
层主要完成对实体(Entity
)的CRUD
操作,因此简称为EAO
层。DAO
层在MyBatis
中也被称为Mapper
层,其通过SQL
语句的映射完成CRUD
操作。
业务逻辑层
业务逻辑层由一系列的业务逻辑对象组成,这些业务逻辑对象实现了系统所需要的业务逻辑方法。这些业务逻辑方法可能仅仅用于暴露领域对象
所实现的业务逻辑方法,也可能是依赖DAO组件实现的业务逻辑方法。
控制器层
控制器层由一系列控制器组成,这些控制器用于拦截用户请求,并调用业务逻辑组件的业务逻辑方法,处理用户请求,并根据处理结果向不同的表现层组件转发。
表现层
表现层由一系列的JSP
页面、Velocity
页面、PDF
文档视图组件组成,负责收集用户请求,并显示处理结果。
大致上,JavaEE
应用的架构如图1.1所示。
各层的JavaEE
组件之间以松耦合的方式组织在一起,各组件并不以硬编码方式耦合,这种方式是为了应用以后的扩展性。从上向下,上面组件的实现依赖于下面组件的功能;从下向上,下面组件支持上面组件的实现。
1.1.2JavaEE应用的组件
Java EE
应用大致包括如下几类组件:
表现层组件
表现层组件主要负责收集用户输入数据,或者向客户显示系统状态。最常用的表现层技术是JSP
,但JSP
并不是唯一的表现层技术。表现层还可由Velocity
、FreeMarker
和Tapestry
等技术完成,或者使用普通的应用程序充当表现层组件,甚至可以是小型智能设备。
控制器组件
JavaEE
的MVC
框架提供了一个前端核心控制器,核心控制器负责拦截用户请求,并将请求转发给用户实现的控制器组件。这些用户实现的控制器组件则负责调用业务逻辑方法,处理用户请求。
业务逻辑组件
业务逻辑组件可以实现系统的业务逻辑,是系统的核心组件。通常,一个业务业务逻辑方法对应一次用户操作。一个业务逻辑方法应该是一个整体,因此要求对业务逻辑方法增加事务性。业务逻辑方法仅仅负责实现业务逻辑,不应该进行数据库访问。因此,业务逻辑组件中不应该出现原始的MyBatis
、Hibernate
和JDBC
等API
。
提示
保证业务逻辑组件之中不出现MyBatis
、Hibernate
和JDBC
等API
,有一个更重要的原因:保证业务逻辑方法的实现与具体的持久层访问技术分离。当系统需要在不同持久层技术之间切换时,系统的业务逻辑组件无须任何改变。有时会见到一些所谓的JavaEE
应用,居然在JSP
页面里面调用SqlSessionFactory
、SqlSession
等API
,这无疑是非常荒唐的,这种应用仅仅是使用MyBatis
,完全没有脱离Model1
的JSP
开发模式,这是相当失败的结构。实际上,不仅JSP
,Servlet
中也不应出现JDBC
、MyBatis
、Hibernate
等持久层API
,最理想的情况是,业务逻辑组件中都不应出现持久层`API`。
DAO组件
DAO
组件的对象比较缺乏变化,每个DAO
组件都提供了对领域对象(DomainObject)
的创建、查询、更新和删除等基本操作,这些操作对应于数据库的CRUD
(创建、查询、更新和删除)等原子操作。当然,如果采用不同的持久层访问技术,DAO
组件的实现会完全不同。为了业务逻辑组件的实现与DAO
组件的实现实现分离,程序应该为每个DAO
组件都提供接口,业务逻辑组件面向DAO
接口编程,这样才能提供更好的解耦。
领域对象组件
领域对象(DomainObject
)抽象了系统的对象模型。通常而言,这些领域对象的状态都必须保存在数据库里。因此,每个领域对象通常对应一个或多个数据表,领域对象通常需要提供对数据记录的访问方式。
1.1.3 Java EE应用的结构和优势
作为Java EE
的初学者,常常有一个问题:明明可以使用JSP
完成这个系统,为什么还要使用MyBatis
和Hibernate
等技术?难道仅仅是为了听起来高深一些?明明可以使用纯粹的JSP
完成整个系统,为什么还要将系统分层?
要回答这些问题,就不能仅仅考虑系统开发过程,还需要考虑系统后期的维护扩展;而且不能仅仅考虑小型系统,还要考虑大型系统的协同开发。如果是用于个人学习、娱乐的个人站点,的确没有必要使用复杂的Java EE
应用架构,采用纯粹的JSP
就可以实现整个系统。
但对于大型的信息化系统,采用Java EE
应用架构则有很大的优势
对于信息化系统,前期开发工作对整个系统工作量而言,仅仅是小部分,而后期的维护、升级往往占更大的比重。更极端的情况是,可能在前期开发期间,企业需求已经发生变化,而这种改变是客观的,软件系统必须适应这种改变,这要求软件系统具有很好的扩展性。
这种框架结构其目的是让应用的各组件以松耦合的方式组织在一起,让应用之间的耦合停留在接口层次,而不是代码层次。
原文链接: 1.1 JavaEE应用概述