PetShop4项目和详细文档

petshop4.0 详解之一（系统架构设计） 

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

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

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

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

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

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

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

的 ，"，#，$ 的操作。如果要加入 %&' 的元素，那么就会包括对象和数据表

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

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

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

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

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

表示层：是系统的 #" 部分，负责使用者与整个系统的交互。在这一层中，理想的状态是不应包括系统的

业务逻辑。表示层中的逻辑代码，仅与界面元素有关。在  中，是利用 ) 来设计的，因

此包含了许多 * 控件和相关逻辑。

分层式结构究竟其优势何在？'+, 在《)

)》一书中给出了答案：

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

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

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

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

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

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

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

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

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

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

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

-、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以

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

层式结构，如图三：

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

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

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

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

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

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

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

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

比较 . 和  的系统架构图，其核心的内容并没有发生变化。在数据访问层（$)2）中，仍然采用

$)2" 抽象出数据访问逻辑，并以 $)2+ 作为数据访问层对象的工厂模块。对于 $)2

" 而言，分别有支持 '!32 的 324$)2 和支持 % 的 %$)2 具体实现。