Pet Shop 4 架构与技术分析

Microsoft .NET Pet Shop 4 架构与技术分析 

 是一个范例，微软用它来展示 企业系统开发的能力。业界有许多 与  之争，许多

数据是从微软的  和  的  而来。这种争论不可避免带有浓厚的商业色彩，对于我们

开发人员而言，没有必要过多关注。然而  随着版本的不断更新，至现在基于 的

 为止，整个设计逐渐变得成熟而优雅，却又很多可以借鉴之处。 是一个小型的项

目，系统架构与代码都比较简单，却也凸现了许多颇有价值的设计与开发理念。本系列试图对 

作一个全方位的解剖，依据的代码是 ，可以从链接 

 !

中获得。

#、 

数据访问层之消息处理 

、 

之 



$% 

&、 

之业务逻辑层设计 

'、 

之表示层设计 

作一个全方位的解剖，依据的代码是

http://msdn.microsoft.com/

library/default.asp?url=/library/en-us/dnbda/html/bdasamppet4.asp

中获得。

一、PetShop 的系统架构设计

在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。微软推荐的分层式结构一般分

为三层，从下至上分别为：数据访问层、业务逻辑层（又或成为领域层）、表示层，如图所示：

图一：三层的分层式结构

数据访问层：有时候也称为是持久层，其功能主要是负责数据库的访问。简单的说法就是实现对数据表

的 ，(，)，* 的操作。如果要加入 +,- 的元素，那么就会包括对象和数据表

之间的 .，以及对象实体的持久化。在  的数据访问层中，并没有使用 +,-，从而导致

了代码量的增加，可以看作是整个设计实现中的一大败笔。

业务逻辑层：是整个系统的核心，它与这个系统的业务（领域）有关。以  为例，业务逻辑层的

相关设计，均和网上宠物店特有的逻辑相关，例如查询宠物，下订单，添加宠物到购物车等等。如果涉

及到数据库的访问，则调用数据访问层。

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

一个好的分层式结构，可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口，负责不同逻

辑设计的开发人员就可以分散关注，齐头并进。例如 )( 人员只需考虑用户界面的体验与操作，领域的设

计人员可以仅关注业务逻辑的设计，而数据库设计人员也不必为繁琐的用户交互而头疼了。每个开发人

员的任务得到了确认，开发进度就可以迅速的提高。

松散耦合的好处是显而易见的。如果一个系统没有分层，那么各自的逻辑都紧紧纠缠在一起，彼此间相

互依赖，谁都是不可替换的。一旦发生改变，则牵一发而动全身，对项目的影响极为严重。降低层与层

间的依赖性，既可以良好地保证未来的可扩展，在复用性上也是优势明显。每个功能模块一旦定义好统

一的接口，就可以被各个模块所调用，而不用为相同的功能进行重复地开发。

进行好的分层式结构设计，标准也是必不可少的。只有在一定程度的标准化基础上，这个系统才是可扩

展的，可替换的。而层与层之间的通信也必然保证了接口的标准化。

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

图二： 中标准的 3 分层式结构

随着  版本的更新，其分层式结构也在不断的完善，例如 ，就没有采用标准的三层

式结构，如图三：

图三： 的体系架构

从图中我们可以看到，并没有明显的数据访问层设计。这样的设计虽然提高了数据访问的性能，但也同

时导致了业务逻辑层与数据访问的职责混乱。一旦要求支持的数据库发生变化，或者需要修改数据访问

的逻辑，由于没有清晰的分层，会导致项目作大的修改。而随着硬件系统性能的提高，以及充分利用缓

存、异步处理等机制，分层式结构所带来的性能影响几乎可以忽略不计。

# 纠正了此前层次不明的问题，将数据访问逻辑作为单独的一层独立出来：

图四：# 的体系架构

 基本上延续了 # 的结构，但在性能上作了一定的改进，引入了缓存和异步处理机制，同

时又充分利用了 $ 的新功能 -，因此  的系统架构图如下所示：

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

可以看到，在数据访问层中，完全采用了“面向接口编程”思想。抽象出来的 (*$4 模块，脱离了与具体数

据库的依赖，从而使得整个数据访问层利于数据库迁移。*$40 模块专门管理 *$4 对象的创建，

便于业务逻辑层访问。546*$4 和 +*$4 模块均实现 (*$4 模块的接口，其中包含的逻辑就

是对数据库的 ，(，) 和 * 操作。因为数据库类型的不同，对数据库的操作也有

所不同，代码也会因此有所区别。

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

图七中 344 是业务逻辑层的核心模块，它包含了整个系统的核心业务。在业务逻辑层中，不能直接访问

数据库，而必须通过数据访问层。注意图中对数据访问业务的调用，是通过接口模块 (*$4 来完成的。既

然与具体的数据访问逻辑无关，则层与层之间的关系就是松散耦合的。如果此时需要修改数据访问层的

具体实现，只要不涉及到 (*$4 的接口定义，那么业务逻辑层就不会受到任何影响。毕竟，具体实现的

546*$4 和 +*$4 根本就与业务逻辑层没有半点关系。

因为在  中引入了异步处理机制。插入订单的策略可以分为同步和异步，两者的插入策略明

显不同，但对于调用者而言，插入订单的接口是完全一样的，所以  中设计了

(344. 模块。虽然在 (344. 模块中，仅仅是简单的 (+.，但同时也给出了一

个范例和信息，那就是在业务逻辑的处理中，如果存在业务操作的多样化，或者是今后可能的变化，均

应利用抽象的原理。或者使用接口，或者使用抽象类，从而脱离对具体业务的依赖。不过在  中，

由于业务逻辑相对简单，这种思想体现得不够明显。也正因为此， 将核心的业务逻辑都放到了