1.4　Java EE项目的分层架构模式

在传统的系统设计中，会将数据库的访问、业务逻辑及可视元素等代码混杂在一起，这样虽然直观，但是代码的可读性差、耦合度高，会为日后的维护和重构带来不便。为了解决这个问题，有人提出了分层架构思想，即将各个功能分开，放在独立的层中，使各层通过协作来实现整体功能。使用分层架构设计容易实现如下目的：分散关注、松散耦合、逻辑复用、标准定义。

1.4.1　分层架构模式概述

分层（Layer）模式是非常常见的一种架构模式，甚至可以说，分层模式是很多架构模式的基础。分层描述的是这样一种架构设计过程：从最低级别的抽象开始，称为第1层，这是系统的基础；通过将第J层放置在第J-1层的上面来逐步向上完成抽象阶梯，直到到达功能的最高级别，称为第N层。

因此分层模式可以定义为：将解决方案的组件分隔到不同的层中，同时每一层中的组件应保持内聚性，并且应大致在同一抽象级别，每一层都应与它下面的各层保持松散耦合。

分层模式的关键在于确定依赖，即通过分层可以限制子系统间的依赖关系，使系统以更松散的方式耦合，从而更易于维护。

●伸缩性：伸缩性指的是应用程序是否能支持更多的用户。应用的层数越少，则可以增加资源（如CPU和内存）的地方就越少；层数越多，则可以将每一层分布在不同的机器上。

●可维护性：可维护性指的是当发生需求变化时，只需修改软件的某一部分代码，不会影响其他部分的代码。

●可扩展性：可扩展性指的是在现有系统中增加新功能的难易程度。层数越多，则可以在每一层中提供扩展点，不会打破应用的整体框架。

●可重用性：可重用性指的是程序代码没有冗余，同一个程序能满足多种需求。例如，业务逻辑层可以由多种表示层共享。

●可管理性：可管理性指的是管理系统的难易程度。在将应用程序分为多层后，可以将工作分解给不同的开发小组，从而便于管理。应用越复杂，规模越大，则需要的层就越多。

在分层架构的设计中，需要遵循以下原则。

●单向逐层调用原则：现在约定将N层架构的各层依次编号为1、2、…、K、…、N-1、N，其中层的编号越大，则越处在上层。同时要求第K（1＜K≤N）层只可依赖第K-1层，而不可依赖其他层。那么，如果第P层依赖第Q层，则P一定大于Q。

●面向接口编程原则：接口是一组规则的集合，它规定了实现本接口的类或接口必须拥有的一组规则，体现了自然界“如果你是……则必须能……”的理念。现在仍约定将N层架构的各层依次编号为1、2、…、K、…、N-1、N，其中层的编号越大，则越处在上层。同时要求第K层不应该依赖具体的第K-1层，而应该依赖一个第K-1层的接口，即在第K层中不应该有第K-1层中的某个具体类。

●封装变化原则：找出应用中可能需要变化的代码，并将它们独立出来，避免它们和那些不需要变化的代码混杂在一起。

●开闭原则：对扩展开放，对修改关闭。具体到N层架构中，可以描述为：当第K-1层有一个新的具体实现时，它应该可以在不修改第K层的情况下，与第K层无缝连接，顺利交互。

●单一职责原则：任何一个类都应该有单一的职责，属于单独的一层，不能同时担负两种职责或属于多个层。

●接口平行原则：某一实体对应的接口组应该是平级且平行的，不应该跨越多个实体或多个级别。

1.4.2　Java Web应用中的三层结构

Java EE项目以Java Web应用为主。在Java Web应用系统开发中，比较流行三层结构（不包括后台数据库），即将系统分为表示层、业务逻辑层和数据访问层。

●表示层：表示层位于最外层（最上层），离用户最近。该层用于显示数据和接收用户输入的数据，为用户提供一种交互式操作的界面。该层会对流入的数据的正确性和有效性负责，对呈现样式负责，对呈现的错误信息负责。

●业务逻辑层：业务逻辑层处于数据访问层与表示层中间，在数据交换中具有承上启下的作用。由于层是一种弱耦合结构，层与层之间的依赖是向下的，下层对于上层而言是“无知”的，改变上层的设计对于其调用的下层而言没有任何影响。如果在分层设计时遵循了面向接口设计的思想，则这种向下的依赖也应该是一种弱依赖关系。因此在不改变接口定义的前提下，理想的分层式架构应该是一个支持可抽取、可替换的“抽屉”式架构。而且业务逻辑层的设计对一个支持可扩展的架构尤为关键，因为它扮演了两个不同的角色：对于数据访问层而言，业务逻辑层是调用者；对于表示层而言，业务逻辑层却是被调用者。依赖与被依赖的关系都处于业务逻辑层。业务逻辑层不仅负责系统领域业务的处理，还负责逻辑性数据的生成、处理及转换。

●数据访问层：数据访问层有时也被称为持久化层，主要负责数据库的访问，可以访问数据库系统、二进制文件、文本文档或XML文档。简单来说，数据访问层可以实现对数据表的Select、Insert、Update、Delete等操作。如果要加入ORM（Object Relation Mapping）的元素，数据访问层就会包括对象和数据表之间的Mapping（映射），以及对象实体的持久化。数据访问层不负责数据的正确性和可用性，不了解数据的用途，不负责任何业务逻辑。

1.4.3　结合MVC模式的分层结构

MVC思想表示将一个应用分成Model（模型）、View（视图）、Control（控制）3个模块。这3个模块以最少的耦合协同工作，从而提高应用的可扩展性和维护性。其中，模型模块用于实现系统中的业务逻辑，通常用JavaBean或EJB来实现。视图模块用于与用户的交互，通常用JSP或JSF来实现。控制模块是模型模块与视图模块之间沟通的桥梁，它可以分配用户的请求并选择恰当的视图来显示，同时它可以解释用户的输入并将它们映射为模型模块可执行的操作。按这种模式设计程序，多个视图模块可以对应一个模型模块，模型模块返回的数据可以与显示逻辑分离，从而使得程序结构清晰、易于维护。

在前文所述的三层结构中，业务逻辑层具有关键的作用，它隔离了表示层和数据访问层，使系统易于维护和扩展。但是，这样的分层结构并没有解决表示层的问题。在表示层中，处理用户的请求、调用业务功能、显示界面等功能代码还混杂在一起，并且在JSP中还经常嵌入Java代码，使这部分代码难以重用，导致程序的结构不清晰。为此，结合MVC模式，可以将三层结构中的表示层进一步划分为视图层和控制层，使得页面与控制逻辑分离，程序结构清晰，便于重用和维护。这种结合MVC模式的分层结构的具体对应关系如图1-42所示。

1.4.4　网上人才中心系统分析与设计

在网络经济环境下，网络招聘以其效率高、成本低、覆盖面广等优势显示出了巨大的发展潜力。网上人才中心系统的设计目的就是为企业和人才搭建一个桥梁，并借助网络，实现企业和人才的交互选择。

1.需求描述

网上人才中心系统的主要功能就是让个人用户（人才）通过网络快速找到自己满意的工作，让企业通过网络发布和管理招聘信息，对应聘者进行回复。网上人才中心系统主要提供以下功能。

●个人用户和企业用户均可在系统中注册，并在注册后可登录。对不同的用户显示不同的状态。

●在企业用户登录后，可以发布招聘信息、管理应聘信息、回复应聘者，以及浏览、查询和查看人才信息。

●在个人用户登录后，可以修改个人信息、查询和查看企业信息、查询职位、申请职位（即应聘）、管理个人申请。

●在管理员登录后，可以管理企业、管理用户、管理权限、管理角色、管理新闻，并修改管理员密码。

●系统能够验证用户的权限，使得不同的用户具有不同的权限。

2.用例分析

用例图用于显示外部参与者与系统的交互，能够更直观地描述系统的功能。从角色来看，网上人才中心系统的用户分为个人用户、企业用户和管理员。如图1-43、图1-44和图1-45所示为网上人才中心系统的3个用例图。

3.功能描述

网上人才中心系统的功能划分如表1-3所示。

4.其他需求

根据用户对本系统的需求，系统应当在响应时间、可靠性、安全性等方面具有较高的性能。

1）界面需求

系统的界面需求如下所述。

●页面内容：主题突出，栏目、菜单的设置和布局合理，传递的信息准确、及时；内容丰富，文字准确，语句通顺；站点定义、术语和行文格式统一、规范、明确。

●导航结构：页面具有明确的导航指示，并且便于理解，方便用户使用。

●技术环境：页面大小适当，可以使用各种常用浏览器以不同分辨率浏览；无错误链接和空链接；采用CSS处理，控制字体大小和版面布局。

●艺术风格：界面、版面形象清新悦目、布局合理；字号大小适宜、字体选择合理，前后一致，美观大方；动与静搭配恰当，动静效果好；色彩和谐自然，与主题内容协调。

2）响应时间需求

用户在系统中进行任何操作时，系统都应当及时地进行反应，反应的时间应控制在5秒以内。系统应当能够监测出各种非正常情况，如与设备的通信中断，无法连接数据库服务器等，避免出现让用户长时间等待甚至无响应的情况。

3）可靠性需求

系统应当保证2000人可以同时在客户端登录，并正常运行，正确提示相关内容。

4）开放性需求

系统应当具有较大的灵活性，以适应将来功能扩展的需求。

5）可扩展性需求

系统应当具有可扩展性，以适应将来功能扩展的需求。

6）系统安全性需求

系统应当具有严格的权限管理功能，其各功能模块需要用户具有相应的权限才能进入。系统应当能够防止各类误操作可能造成的数据丢失、损坏等情况，防止用户非法获取网页及内容。

5.系统设计

1）系统功能结构

网上人才中心系统的功能结构如图1-46所示。

2）数据库设计

根据企业信息展示系统的要求，主要涉及用户、角色、权限、个人、企业、招聘、应聘、新闻等数据，因此建立10个数据表用来存储对应的数据。

将系统数据库命名为rc，并将10个数据表分别命名为rc_user（用户）、rc_person（个人）、rc_role（角色）、rc_permission（权限）、rc_user_role（用户角色）、rc_role_permission（角色权限）、rc_company（企业）、rc_job（工作）、rc_application（申请）、rc_news（新闻）。各个数据表及其关系如图1-47所示。

3）实体类设计

网上人才中心系统主要包含如下实体类（也称为数据模型类）：RcUser（用户类）、RcRole（角色类）、RcPermission（权限类）、RcPerson（个人）、RcCompany（企业）、RcJob（工作，即职位）、RcApplication（申请，即应聘）、RcNews（新闻）。这些类均被存放在com.rc.entity包下。UML类图如图1-48所示，该类图隐藏了属性方法。

在建立这些类时，需要注意以下几点。

（1）每个实体类都要有一个无参数的构造函数。

（2）每个实体类要实现Serializable接口。

（3）RcJob类和RcCompany类是多对一单向关联的关系。

（4）RcApplication类和RcJob类及RcPerson类均是多对一单向关联的关系。

（5）RcPerson类和RcUser类，以及RcCompany类和RcUser类均是多对一单向关联的关系。

4）业务逻辑层接口设计

业务逻辑层接口体现了业务功能的需要，反映了系统所具有的业务功能。业务逻辑层接口主要包括RcUserService（用户业务逻辑接口）、RcRoleService（角色业务逻辑接口）、RcPermissionService（权限业务逻辑接口）、RcPersonService（个人业务逻辑接口）、RcCompanyService（企业业务逻辑接口）、RcJobService（职位业务逻辑接口）、RcApplicationService（申请业务逻辑接口）、RcNewsService（新闻业务逻辑接口）。这些接口均被存放在com.rc.service包下。业务逻辑层接口图如图1-49所示。

5）数据访问层接口设计

数据访问层用于实现对数据库的访问，其接口定义了数据访问的方法。数据访问层接口主要包括RcUserDao（用户数据访问接口）、RcRoleDao（角色数据访问接口）、RcPermissionDao（权限数据访问接口）、RcPersonDao（个人数据访问接口）、RcCompanyDao（企业数据访问接口）、RcJobDao（职位数据访问接口）、RcApplicationDao（申请数据访问接口）、RcNewsDao（新闻数据访问接口）。这些接口均被存放在com.rc.dao包下。数据访问层接口图如图1-50所示。

6）总体界面设计

为了使网页具有代码简练、容易重构、访问速度快、搜索引擎友好、浏览器兼容性好等特点，界面的结构布局主要使用DIV标签并与CSS结合来实现。

（1）绘制界面效果图。

使用Photoshop等绘图工具绘制界面效果图，如图1-51所示。

（2）系统界面结构分析。

系统界面有4个主要区域，即题头区（header）、菜单（menu）、主体区（pagebody）及页脚区（footer），其中主体区包含左区（left）和右区（right）。系统界面的结构布局如图1-52所示。

（3）确定DIV标签的层次及命名。

DIV标签的层次及命名如图1-53所示。

（4）设计系统首页。

使用HTML进行系统首页设计，代码如下：

（5）建立样式表文件all.css。

在css文件夹下建立all.css文件，并编写代码如下：