项目分解：
由于整体已经有22个项目，所以，对于初学者一看就晕了，所以，我做了分解，可以大体上分几块去理解。
序号 项目名称 描述
1 WEB 表示层
2 Model 业务实体
3 BLL 业务逻辑层
4 DALFactory 数据层的抽象工厂
5 IDAL 数据访问层接口定义
6 SQLServerDAL SQLServer数据访问层
7 OracleDAL Oracle数据访问层
8 DBUtility 数据库访问组件基础类
9 CacheDependencyFactory 缓存依赖类的工厂类
10 ICacheDependency 缓存依赖类接口
11 TableCacheDependency 缓存依赖实现类
12 IBLLStrategy 同步/异步处理策略接口(实现在bll根据配置反射选择)
13 MessagingFactory 异时处理消息队列的抽象工厂
14 IMessaging 异时处理消息队列接口定义
15 MSMQMessaging 异时处理消息队列的实现
16 Profile Profile的数据访问层
17 ProfileDALFactory ProfileDAL的工厂类(反射创建ProfileDAL)
18 IProfileDAL Profile的数据访问层接口定义
19 OracleProfileDAL Oracle的Profile Providers 做用户状态管理
20 SQLProfileDAL SQL Server 的Profile Providers 做用户状态管理
21 Membership Membership认证和授权管理
22 OrderProcessor 后台处理进程，处理订单队列
|
序号
|
项目名称
|
程序集名称Assembly Name |
默认命名空间Default Namespace |
描述
|
|
1
|
WEB
|
|
|
表示层
|
|
2
|
Model
|
PetShop.Model |
PetShop.Model |
业务实体
|
|
3
|
BLL
|
PetShop.BLL |
PetShop.BLL |
业务逻辑层
|
|
4
|
DALFactory
|
PetShop.DAL |
PetShop.DALFactory |
数据层的抽象工厂
|
|
5
|
IDAL
|
PetShop.IDAL |
PetShop.IDAL |
数据访问层接口定义
|
|
6
|
SQLServerDAL
|
PetShop.SQLServerDAL |
PetShop.SQLServerDAL |
SQLServer数据访问层
|
|
7
|
OracleDAL
|
PetShop.OracleDAL |
PetShop.OracleDAL |
Oracle数据访问层
|
|
8
|
DBUtility
|
PetShop.DBUtility |
PetShop.DBUtility |
数据库访问组件基础类
|
|
9
|
CacheDependencyFactory
|
PetShop.CacheDependencyFactory |
PetShop.CacheDependencyFactory |
缓存依赖类的工厂类
|
|
10
|
ICacheDependency
|
PetShop.ICacheDependency |
PetShop.ICacheDependency |
缓存依赖类接口
|
|
11
|
TableCacheDependency
|
PetShop.TableCacheDependency |
PetShop.TableCacheDependency |
缓存依赖实现类
|
|
12
|
IBLLStrategy
|
PetShop.IBLLStrategy |
PetShop.IBLLStrategy |
同步/异步处理策略接口(实现在bll根据配置反射选择)
|
|
13
|
MessagingFactory
|
PetShop.MessagingFactory |
PetShop.MessagingFactory |
异时处理消息队列的抽象工厂
|
|
14
|
IMessaging
|
PetShop.IMessaging |
PetShop.IMessaging |
异时处理消息队列接口定义
|
|
15
|
MSMQMessaging
|
PetShop.MsmqMessaging |
PetShop.MsmqMessaging |
异时处理消息队列的实现
|
|
16
|
Profile
|
PetShop.Profile |
PetShop.Profile |
Profile的数据访问层
|
|
17
|
ProfileDALFactory
|
PetShop.ProfileDALFactory |
PetShop.ProfileDALFactory |
ProfileDAL的工厂类(反射创建ProfileDAL)
|
|
18
|
IProfileDAL
|
PetShop.IProfileDAL |
PetShop.IProfileDAL |
Profile的数据访问层接口定义
|
|
19
|
OracleProfileDAL
|
PetShop.OracleProfileDAL |
PetShop.OracleProfileDAL |
Oracle的Profile Providers
做用户状态管理
|
|
20
|
SQLProfileDAL
|
PetShop.SQLProfileDAL |
PetShop.SQLProfileDAL |
SQL Server 的Profile Providers
做用户状态管理
|
|
21
|
Membership
|
PetShop.Membership |
PetShop.Membership |
Membership认证和授权管理
|
|
22
|
OrderProcessor
|
PetShop.OrderProcessor |
PetShop.OrderProcessor |
后台处理进程，处理订单队列
|
一、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则提供缓存功能。这些特殊的模块，我会在此后的文章中详细介绍。