petshop4.0 详解之一

 

一、 PetShop 的系统架构设计

在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。微软推荐的分层式结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层（又或成为领域层）、表示层，如图所示  

图一：三层的分层式结构

数据访问层：有时候也称为是持久层，其功能主要是负责数据库的访问。简单的说法就是实现对数据表的 Select ， Insert ， Update ， Delete 的操作。如果要加入 ORM 的元素，那么就会包括对象和数据表之间的 mapping ，以及对象实体的持久化。在 PetShop 的数据访问层中，并没有使用 ORM ，从而导致了代码量的增加，可以看作是整个设计实现中的一大败笔。

业务逻辑层：是整个系统的核心，它与这个系统的业务（领域）有关。以 PetShop 为例，业务逻辑层的相关设计，均和网上宠物店特有的逻辑相关，例如查询宠物，下订单，添加宠物到购物车等等。如果涉及到数据库的访问，则调用数据访问层。

表示层：是系统的 UI 部分，负责使用者与整个系统的交互。在这一层中，理想的状态是不应包括系统的业务逻辑。表示层中的逻辑代码，仅与界面元素有关。在 PetShop 中，是利用 ASP.Net 来设计的，因此包含了许多 Web 控件和相关逻辑。

分层式结构究竟其优势何在？ Martin Fowler 在《 Patterns of Enterprise Application Architecture 》一书中给出了答案：

1 、开发人员可以只关注整个结构中的其中某一层；

2 、可以很容易的用新的实现来替换原有层次的实现；

3 、可以降低层与层之间的依赖；

4 、有利于标准化；

5 、利于各层逻辑的复用。

概括来说，分层式设计可以达至如下目的：分散关注、松散耦合、逻辑复用、标准定义。

一个好的分层式结构，可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口，负责不同逻辑设计的开发人员就可以分散关注，齐头并进。例如 UI 人员只需考虑用户界面的体验与操作，领域的设计人员可以仅关注业务逻辑的设计，而数据库设计人员也不必为繁琐的用户交互而头疼了。每个开发人员的任务得到了确认，开发进度就可以迅速的提高。

松散耦合的好处是显而易见的。如果一个系统没有分层，那么各自的逻辑都紧紧纠缠在一起，彼此间相互依赖，谁都是不可替换的。一旦发生改变，则牵一发而动全身，对项目的影响极为严重。降低层与层间的依赖性，既可以良好地保证未来的可扩展，在复用性上也是优势明显。每个功能模块一旦定义好统一的接口，就可以被各个模块所调用，而不用为相同的功能进行重复地开发。

进行好的分层式结构设计，标准也是必不可少的。只有在一定程度的标准化基础上，这个系统才是可扩展的，可替换的。而层与层之间的通信也必然保证了接口的标准化。

“ 金无足赤，人无完人 ” ，分层式结构也不可避免具有一些缺陷：

1 、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。

2 、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。

前面提到， PetShop 的表示层是用 ASP.Net 设计的，也就是说，它应是一个 BS 系统。在 .Net 中，标准的 BS 分层式结构如下图所示：

图二： .Net 中标准的 BS 分层式结构

随着 PetShop 版本的更新，其分层式结构也在不断的完善，例如 PetShop2.0 ，就没有采用标准的三层式结构，如图三：

图三： PetShop 2.0 的体系架构

从图中我们可以看到，并没有明显的数据访问层设计。这样的设计虽然提高了数据访问的性能，但也同时导致了业务逻辑层与数据访问的职责混乱。一旦要求支持的数据库发生变化，或者需要修改数据访问的逻辑，由于没有清晰的分层，会导致项目作大的修改。而随着硬件系统性能的提高，以及充分利用缓存、异步处理等机制，分层式结构所带来的性能影响几乎可以忽略不计。

PetShop3.0 纠正了此前层次不明的问题，将数据访问逻辑作为单独的一层独立出来：

图四： PetShop 3.0 的体系架构

PetShop4.0 基本上延续了 3.0 的结构，但在性能上作了一定的改进，引入了缓存和异步处理机制，同时又充分利用了 ASP.Net 2.0 的新功能 MemberShip ，因此 PetShop4.0 的系统架构图如下所示：

图五： PetShop 4.0 的体系架构

比较 3.0 和 4.0 的系统架构图，其核心的内容并没有发生变化。在数据访问层（ DAL ）中，仍然采用 DAL Interface 抽象出数据访问逻辑，并以 DAL Factory 作为数据访问层对象的工厂模块。对于 DAL Interface 而言，分别有支持 MS-SQL 的 SQL Server DAL 和支持 Oracle 的 Oracle DAL 具体实现。而 Model 模块则包含了数据实体对象。其详细的模块结构图如下所示：

图六：数据访问层的模块结构图

可以看到，在数据访问层中，完全采用了 “面向接口编程”思想。抽象出来的IDAL 模块，脱离了与具体数据库的依赖，从而使得整个数据访问层利于数据库迁移。 DALFactory 模块专门管理 DAL 对象的创建，便于业务逻辑层访问。 SQLServerDAL 和 OracleDAL 模块均实现 IDAL 模块的接口，其中包含的逻辑就是对数据库的 Select ， Insert ， Update 和 Delete 操作。因为数据库类型的不同，对数据库的操作也有所不同，代码也会因此有所区别。

此外，抽象出来的 IDAL 模块，除了解除了向下的依赖之外，对于其上的业务逻辑层，同样仅存在弱依赖关系，如下图所示：

图七：业务逻辑层的模块结构图

图七中 BLL 是业务逻辑层的核心模块，它包含了整个系统的核心业务。在业务逻辑层中，不能直接访问数据库，而必须通过数据访问层。注意图中对数据访问业务的调用，是通过接口模块 IDAL 来完成的。既然与具体的数据访问逻辑无关，则层与层之间的关系就是松散耦合的。如果此时需要修改数据访问层的具体实现，只要不涉及到 IDAL 的接口定义，那么业务逻辑层就不会受到任何影响。毕竟，具体实现的 SQLServerDAL 和 OracalDAL 根本就与业务逻辑层没有半点关系。

因为在 PetShop 4.0 中引入了异步处理机制。插入订单的策略可以分为同步和异步，两者的插入策略明显不同，但对于调用者而言，插入订单的接口是完全一样的，所以 PetShop 4.0 中设计了 IBLLStrategy 模块。虽然在 IBLLStrategy 模块中，仅仅是简单的 IOrderStategy ，但同时也给出了一个范例和信息，那就是在业务逻辑的处理中，如果存在业务操作的多样化，或者是今后可能的变化，均应利用抽象的原理。或者使用接口，或者使用抽象类，从而脱离对具体业务的依赖。不过在 PetShop 中，由于业务逻辑相对简单，这种思想体现得不够明显。也正因为此， PetShop 将核心的业务逻辑都放到了一个模块 BLL 中，并没有将具体的实现和抽象严格的按照模块分开。所以表示层和业务逻辑层之间的调用关系，其耦合度相对较高：

 

图八：表示层的模块结构图

在图五中，各个层次中还引入了辅助的模块，如数据访问层的 Messaging 模块，是为异步插入订单的功能提供，采用了 MSMQ （ Microsoft Messaging Queue ）技术。而表示层的 CacheDependency 则提供缓存功能。这些特殊的模块，我会在此后的文章中详细介绍。