《解剖
PetShop
》系列之一
前言：
PetShop
是一个范例，微软用它来展示
.Net
企业系统开发的能力。业界有许多
.Net
与
J2EE
之争，许多数据是从微软的
PetShop
和
Sun
的
PetStore
而来。这种争论不可避
免带有浓厚的商业色彩，对于我们开发人员而言，没有必要过多关注。然而
PetShop
随着
版本的不断更新，至现在基于
.Net 2.0
的
PetShop4.0
为止，整个设计逐渐变得成熟而优
雅，却又很多可以借鉴之处。
PetShop
是一个小型的项目，系统架构与代码都比较简单，
却也凸现了许多颇有价值的设计与开发理念。
本系列试图对
PetShop
作一个全方位的解剖，
依据的代码是
PetShop4.0
，可以从链接
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html
/bdasamppet4.asp
中获得。
一、
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
模块，除了解除了向下的依赖之外，对于其上的业务逻辑层，同样
仅存在弱依赖关系，如下图所示：
