1.1 JavaEE应用概述

1.1 JavaEE应用概述

我所讲的应用规范超出了Sun提出的经典Java EE应用规范，而是一种更广泛的开发规范

经典Java EE应用往往以EJB(企业级Java Bean)为核心，以应用服务器为运行环境，所以通

常开发发、运行成本较高。而我介绍的轻量级Java应用具备了Java EE规范的种种特征，例如面向对象建模的思维方式、优秀的应用分层及良好的可扩展性、可维护性。轻量级JavaEE应用保留了经典Java应用的架构，但开发、运行成本更低。

 

1·1·1 JavaEE应用的分层模型

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

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

 

1. DAO(Data Access Object,数据访问对象）层：此层由一系列的DAO组件组成，这些DAO实

2. 现了对数据库的创建、查询、更新和删除(CRUD)等原子操作。

 

提示

在经典JavaEE应用中，DAO层也被改称为EAO层，EAO层组件的作用与DAO层组件的作用基本相似。只是EAO层主要完成对实体(Entity)的CRUD操作，因此简称为EAO层。

 

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

 

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

 

5. 表现层：此层由一系列的JSP页面、velocity页面、PDF文档视图组件组成，负责收集用户请求，并显示处理结果。

 

大致上，JavaEE应用的架构如图1•1所示。

 

 

 

 

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

 

至于以EJB3、JPA为核心的JavaEE应用的结构，和图所示的应用结构大致相似，只是它的

DAO层（一般称为EAO层）组件、业务逻辑层组件都山EJB充当。关于经典JavaEE应用的详细介绍，

 

 

1.1.2 Java EE应用的组件

 

 Java EE架构提供了良好的分离，隔离了各组件之间的代码依赖。

 

总体而言，JavaEE应用大致包括如下几类组件。

 

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

 

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

 

3. 业务逻辑组件：是系统的核心组件，实现系统的业务逻辑。通常，一个业务逻辑方法应该是一个整体，因此要求对业务逻辑方法增加事务性。业务逻辑方法仅仅负责实现业务逻辑，不应该进行数据库访问。因此，业务逻辑组件中不应该出现原始的Hibernate、JDBC等APL。

 

注意：

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

 

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

 

5. 领域区对象组件：领域对象（Domain Object）抽象了系统的对象模型。通俗而言，这些领域区对象的状态都必须保存在数据库里。 因此，每个领域对象通常只对应一个或多个数据表，领域对象通常需要提供对数据记录访问方式。

 

 

1.1.3 Java EE 应用的结构和优势

 

对于Java EE的初学者而言，常常有一个问题：明明可以使用JSP完成这个系统，为什么还要使用Hibernate等技术？难道仅仅是为了听起来高深一点？明明可以使用纯粹的JSP完成整个系统，为什么系统分层。

 

要回答这些问题，就不能仅仅考虑系统开发过程，还需要考虑系统后期的维护、扩展：而且不能仅仅考虑那些小型系统，还要考虑大型系统的协同开发。对于个人学习、娱乐的个人站点，的确没有必要使用复杂的Java EE应用架构，采用纯粹的JSP就可以实现整个系统。

 

对于大型的信息化系统而言，采用Java EE应用架构则有很大的优势。

 

软件不是一次性系统，不仅与传统行业的产品有较大的差异，甚至与硬件产品也有较大的差异。硬件产品可以随时间的流逝而宣布过时，更换新一代硬件产品。但是软件不能彻底替换，只能在其原来的基础上延伸，因为软件往往是信息的延续，是企业命脉的延伸。如果支撑企业系统的软件不具备可扩展性，当企业平台发生改变时，如何面对这种改变？如果新开发的系统不能与老系统有机地融合在一起，那么老系统的信息如何重新利用？这种损失将无法用金钱来衡量。

 

对于信息化系统，前期开发工作对整个系统工作量而言，仅仅是小部分，而后期的维护、升级往往占更大的比重。更极端的情况是，可能在前期开发期间，企业需求己经发生改变。

而软件系统必须适应这种改变，这要求软件系统具有很好的伸缩性。

 

最理想的软件系统应该如同计算机的硬件系统，各种设备可以支持热插拔，各设备之间的影响非常小，设备与设备之间的实现完全透明，只要有通用的接口，设备之间就可以良好协作。虽然，目前软件系统还达不到这种理想状态，但这应该是软件系统努力的方向。

 

上面介绍的这种框架，致力于让应用的各组件以松耦合的方式组织在一起，让应用之间的耦合停留在接口层次，而不是代码层次。

 

1.1.4常用的Java EE服务器

本书将介绍一种优秀的轻量级Java EE架构：Struts2 + Spring + Hibernate。采用这种架构的软件系统，无须专业的Java EE服务器支持，只需要简单的web服务器就可以运行。Java领域常见的Web服务器都是开源的，而且具有很好的稳定性。

 

常见的web服务器有如下三个。

1. Tomcat：Tomcat和Java结合得最好，是Oracle官方推荐的JSP服务器。Tomcat是开源的Web服务器，经过长时间的发展，性能、稳定性等方面都非常优秀。

2. Jetty：另一个优秀的web服务器。Jetty有个更大的优点就是，Jetty可作为一个嵌入式服务器。即：如果在应用中加入Jetty的JAR文件，应用可在代码中对外提供web服务。

3. Resin：目前最快的JSP、Serviet运行平台，支持EJB。个人学习该服务器是免费的，但如果将该服务器用作商业用途，则需要交纳相应的费用。

 

除了上面的web服务器外，还有一些专业的Java EE服务器，相对于web服务器而言，Java EE服务器支持更多的Java EE特性，例如分布式事务、EJB容器等。常用的Java EE服务器有如下几个。

JBoss：开源的JavaEE服务器，全面支持各种最新的Java EE规范。

GlassFish：Oracle官方提供的Java EE服务器，通常能最早支持各种Java EE规范。比如最新

GlassFish可以支持目前最新的Java EE 7。

WebLogic和WebSphere：这两个是专业的商用Java EE服务器，价格不菲。但在性能等各方

也是相当出色的。