1.1 Java EE应用概述

今天所说的Java EE应用,超出了Sun所提出的经典Java EE应用规范,而是一种更泛的开发规范。
经典Java EE应用往往以EJB(企业级JavaBean)为核心,以应用服务器为运行环境,所以开发、运行成本较高。
本书所介绍的Spring MVC+MyBatis作为轻量级Java EE应用不仅具备Java EE规范的种种特征,例如面向对象建模的思维方式、优秀的应用分层及良好的可扩展性、可维护性,而且保留了经典Java EE应用的架构,但其开发、运行成本更低。

1.1.1 Java EE应用的分层模型

不管是经典的Java EE架构，还是本书介绍的轻量级Java EE架构，大致上都可分为如下几层：

领域对象层

领域对象层由一系列的POJO组成，POJO是Plain Old Java Object的缩写，也就是普通的、传统的Java对象,这些传统的Java对象是该系统的领域对象，领域对象往往包含了各自所需实现的业务逻辑方法。

DAO层

DAO是Data Access Object的缩写,所以DAO层也叫数据访问对象层。DAO层由一系列的DAO组件组成，这些**DAO实现了对数据库的创建、查询、更新和删除（CRUD）等原子操作。
注意
在经典Java EE应用中，DAO层也被称为EAO层，EAO层组件的作用与DAO层组件的作用基本相似。只是EAO层主要完成对实体（Entity）的CRUD操作，因此简称为EAO层**。
DAO层在MyBatis中也被称为Mapper层，其通过SQL语句的映射完成CRUD操作。

业务逻辑层

业务逻辑层由一系列的业务逻辑对象组成，这些业务逻辑对象实现了系统所需要的业务逻辑方法。这些业务逻辑方法可能仅仅用于暴露领域对象所实现的业务逻辑方法，也可能是依赖DAO组件实现的业务逻辑方法。

控制器层

控制器层由一系列控制器组成，这些控制器用于拦截用户请求，并调用业务逻辑组件的业务逻辑方法，处理用户请求，并根据处理结果向不同的表现层组件转发。

表现层

表现层由一系列的JSP页面、Velocity页面、PDF文档视图组件组成，负责收集用户请求，并显示处理结果。
大致上，Java EE应用的架构如图1.1所示。

各层的Java EE组件之间以松耦合的方式组织在一起，各组件并不以硬编码方式耦合，这种方式是为了应用以后的扩展性。从上向下，上面组件的实现依赖于下面组件的功能；从下向上，下面组件支持上面组件的实现。

1.1.2JavaEE应用的组件

Java EE应用大致包括如下几类组件：

表现层组件

表现层组件主要负责收集用户输入数据，或者向客户显示系统状态。**最常用的表现层技术是JSP**，但JSP并不是唯一的表现层技术。表现层还可由Velocity、FreeMarker和Tapestry等技术完成，或者使用普通的应用程序充当表现层组件，甚至可以是小型智能设备。

控制器组件

Java EE的MVC框架提供了一个前端核心控制器，核心控制器负责拦截用户请求，并将请求转发给用户实现的控制器组件。这些用户实现的控制器组件则负责调用业务逻辑方法，处理用户请求。

业务逻辑组件

业务逻辑组件可以实现系统的业务逻辑,是系统的核心组件。通常，一个业务业务逻辑方法对应一次用户操作。一个业务逻辑方法应该是一个整体，因此要求对业务逻辑方法增加事务性。

业务逻辑组件中不应出现持久层API

业务逻辑方法仅仅负责实现业务逻辑，不应该进行数据库访问。因此，业务逻辑组件中不应该出现原始的MyBatis、Hibernate和JDBC等API。
提示
保证业务逻辑组件之中不出现MyBatis、Hibernate和JDBC等API，有一个更重要的原因：保证业务逻辑方法的实现与具体的持久层访问技术分离。当系统需要在不同持久层技术之间切换时，系统的业务逻辑组件无须任何改变。
有时会见到一些所谓的Java EE应用，居然在JSP页面里面调用SqlSessionFactory、SqlSession等API，这无疑是非常荒唐的，这种应用仅仅是使用MyBatis，完全没有脱离Model1的JSP开发模式，这是相当失败的结构。实际上，不仅JSP，Servlet中也不应出现JDBC、MyBatis、Hibernate等持久层API,**最理想的情况是，业务逻辑组件中都不应出现持久层API。

DAO组件

DAO组件的对象比较缺乏变化，每个DAO组件都提供了对领域对象(Domain Object)的创建、查询、更新和删除等基本操作，这些操作对应于数据库的CRUD（创建、查询、更新和删除）等原子操作。当然，如果采用不同的持久层访问技术，DAO组件的实现会完全不同。为了业务逻辑组件的实现与DAO组件的实现实现分离，程序应该为每个DAO组件都提供接口，业务逻辑组件面向DAO接口编程，这样才能提供更好的解耦。

领域对象组件

领域对象（Domain Object）抽象了系统的对象模型。

领域对象 对应 数据库表

通常而言，这些领域对象的状态都必须保存在数据库里。因此，每个领域对象通常对应一个或多个数据表，领域对象通常需要提供对数据记录的访问方式。

1.1.3 Java EE应用的结构和优势

作为Java EE的初学者,常常有一个问题:明明可以使用JSP完成这个系统,为什么还要使用MyBatis和Hibernate等技术?难道仅仅是为了听起来高深一些?明明可以使用纯粹的JSP完成整个系统,为什么还要将系统分层?
要回答这些问题,就不能仅仅考虑系统开发过程,还需要考虑系统后期的维护扩展;而且不能仅仅考虑小型系统,还要考虑大型系统的协同开发。如果是用于个人学习、娱乐的个人站点,的确没有必要使用复杂的Java EE应用架构,采用纯粹的JSP就可以实现整个系统。
但对于大型的信息化系统,采用Java EE应用架构则有很大的优势

维护升级要求

对于信息化系统,前期开发工作对整个系统工作量而言,仅仅是小部分,而后期的维护、升级往往占更大的比重。

扩展性要求

更极端的情况是,可能在前期开发期间,企业需求已经发生变化,而这种改变是客观的,软件系统必须适应这种改变,这要求软件系统具有很好的扩展性。

松耦合

这种框架结构其目的是让应用的各组件以松耦合的方式组织在一起,让应用之间的耦合停留在接口层次,而不是代码层次。