下载掌阅APP，畅读海量书库
立即打开
如果读者有大型企业级应用开发经验，则对于分层架构肯定不会陌生。同样，Ability也采用分层架构。本节讨论以下话题：
（1）为什么需要将应用程序进行分层？
（2）如果不分层，系统将会出现哪些问题？
（3）常见的分层方式有哪些？
（4）Ability是如何进行分层的？
随着面向对象程序设计和设计模式的出现，人们发现，现实生活中的建筑学有很多理论可以用来指导软件工程（程序的开发）。例如，在开发时，首先会对要盖的楼房进行评估和核算（软件项目管理）；然后根据需求设计楼房的图纸（软件设计），并把楼房的地基、骨架搭建出来（搭建框架）；接着根据不同工种将人员进行分工，如砌墙、贴砖（前端编码、后台编码）；最后进行验收测试，交付给用户使用。
软件应用开发与建筑学的分层目的是一致的，都是旨在根据不同的业务、不同的技术、不同的组织，结合灵活性、可维护性、可扩展性等多种因素，将应用系统划分成不同的部分，并使这些部分彼此之间相互分工、相互协作，从而体现出最大化价值。对于一个良好分层的应用来说，其一般具备如下特点。
1. 按业务功能进行分层
分层就是将相关的业务功能的类或组件放置在一起，而将不相关的业务功能的类或组件隔离开。例如，将与用户直接交互的部分称为表示层，将实现逻辑计算或者业务处理的部分称为业务层，将与数据库“打交道”的部分称为数据访问层。
2. 良好的层次关系
设计良好的架构分层是上层依赖于下层，而下层支撑起上层，但却不能直接访问上层，层与层之间通过协作共同完成特定的功能。
3. 每一层都能保持独立
层能够被单独构造，也能被单独替换，最终不会影响整体功能。例如，可以将整个数据持久层的技术从Hibernate变成EclipseLink，而不对上层业务逻辑功能造成影响。
为了更好地理解分层的好处，首先来看不分层的应用架构是如何运作的。
这里以一个Web应用程序为例。在Web应用程序开发早期，所有的逻辑代码并没有明显的层次区分，因此代码之间的调用是相互交错的，整体代码看上去错综复杂。例如，在早期使用诸如ASP（Active Server Pages，动态服务器页面）、JSP（Java Server Pages，Java服务器页面）以及PHP（Hypertext Preprocessor，超文本预处理）等动态网页技术时，常会将所有的页面逻辑、业务逻辑以及数据库访问逻辑放在一起，很多时候就在JSP页面中写SQL语句，编码风格完全是过程化的。
以下代码就是一个JSP访问SQL Server数据库的示例：
先不论这段代码是否正确，从实现功能上来说，这段代码既处理了数据库的访问操作，还做了页面的表示，其中又夹杂着业务逻辑判断。所幸这段代码不长，读下来还能够理解，但如果是更加复杂的功能，这种代码肯定是非常不清晰的，维护起来也相当麻烦。
早期的这种不分层的架构主要存在如下弊端。
（1）代码不够清晰，难以阅读。
（2）代码职责不明，难以扩展。
（3）代码错综复杂，难以维护。
（4）代码不做分工，难以组织。
目前比较常用的、典型的应用软件倾向于使用三层架构（Three-Tier Architecture），即表示层（Presentation Layer）、业务层（Business Layer）和数据访问层（Data Access Layer），如图5-2所示。
图5-2 三层架构
（1）表示层：提供与用户交互的界面。GUI（Graphical User Interface，图形用户界面）和Web 页面是表示层的两个典型例子。
（2）业务层：也称为业务逻辑层，用于实现各种业务逻辑，如处理数据验证、根据特定的业务规则和任务响应特定的行为。
（3）数据访问层：也称为数据持久层，负责存放和管理应用的持久性业务数据。
三层构架中的每一个层都需要不同的技能。
（1）表示层需要HTML（HyperText Markup Language，超文本标记语言）、CSS、JS等前端技能，以及具备UI设计能力。
（2）业务层需要编程语言技能，以便计算机可以处理业务规则。
（3）数据访问层需要具有数据定义语言（Data Definition Language，DDL）、数据操纵语言（Data Manipulation Language，DML）以及数据库设计形式的SQL技能。
虽然一个人有可能拥有所有上述技能，但这样的人是相当罕见的。在具有大型软件应用程序的大型组织中，将应用程序分割为单独的层，使得每个层都可以由具有相关专业技能的不同团队开发和维护。
一个良好分层的架构系统应遵循如下分层原则。
（1）每层的代码必须包含可以单独维护的单独文件。
（2）每层只能包含属于该层的代码。因此，业务逻辑只能驻留在业务层，表示逻辑只能驻留在表示层，而数据访问逻辑只能驻留在数据访问层。
（3）表示层只能接收来自外部代理的请求，并向外部代理返回响应。其通常是一个人，但也可能是另一个软件。
（4）表示层只能向业务层发送请求，并从业务层接收响应，而不能直接访问数据库或数据访问层。
（5）业务层只能接收来自表示层的请求，并返回对表示层的响应。
（6）业务层只能向数据访问层发送请求，并从其接收响应，而不能直接访问数据库。
（7）数据访问层只能从业务层接收请求并返回响应，而不能发出请求到除了它支持的数据库管理系统（DataBase Management System，DBMS）以外的任何东西。
（8）每层应完全不知道其他层的内部工作原理。例如，业务层可以对数据库一无所知，并且可以不知道或不必关心数据访问对象的内部工作原理。业务层可以不知道或不关心表示层如何处理它的数据。表示层可以获取数据并构造HTML文档、PDF文档、CSV文件或以某种其他方式处理它，但是这与业务层完全无关。
（9）每层应当可以用具有类似特征的替代组件来交换这个层，使得整体可以继续工作。
简言之，在一开始设计应用时就要考虑系统的架构设计，以及如何将系统进行有效的分层。由于系统架构设计属于比较高级别的话题，因此本书不会涉及太多，对这方面感兴趣的读者可以参阅笔者所著的《分布式系统常用技术及案例分析》一书，该书的第2章详细介绍了软件系统的常见架构体系。
从应用的三层架构中可以很容易识别出，Ability同样遵循图5-2所示的三层架构。其中，Page Ability代表表示层，Service Ability代表业务层，Data Ability代表数据访问层。
因此，开发人员在设计Ability时应先考虑该Ability需要完成什么功能，以及代表哪个层次的业务。