.NET Petshop详解

 .NET PetShop祥解

Microsoft .NET Pet Shop 3.x: .NET Pet Shop 的设计模式与体系结构

Microsoft .NET Pet Shop 4：将 ASP.NET 1.1 应用程序迁移到 2.0

1．项目概述与架构分析
微软刚推出了基于ASP.NET 2.0下的Pet Shop 4, 该版本有了一个全新的用户界面。是研究ASP.NET 2.0的好范例啊，大家都知道，一直以来，在.NET和Java之间争论不休，到底使用哪个平台开发的企业级应用性能最好、结构最优、生产力最高。为了用事实说话，通过对项目各方面的性能评估进而在比较.NET和Java的高下。用户做比较的这个项目就是Petshop。正因为Petshop肩负着上面所说的重任，各方面必须是最优的，架构设计应该是经过慎重考虑的。所以其一经推出，便成为了开发者、架构师等人学习、研究的典范。

日前微软推出了基于.NET Framework 2.0开发的Petshop 4。新的Petshop4实现了与Petshop 3相同甚至更多的特性，由于采用了Master Pages，Membership，以及Profile，SqlCacheDependency，但是代码量却减少了四分之一。同时，在事务、数据缓存、安全方面使用了.NET 2.0附带的特性，构建了一个灵活的最佳实践的应用程序。

 

他们利用了Project Conversion Wizard把项目从ASP.NET 1.1移植到了ASP.NET 2.0，然后做了以下改动：

1．用System.Transactions代替了原来的Serviced Components提供的事务功能

代码实现：PetShop.BLL.OrderSynchronous 的 public void Insert(PetShop.Model.OrderInfo order)。

2．用强类型的范型集合代替了原来的弱类型集合

        public IList<ProductInfo> GetProductsByCategory(string category)

        {

            // Return new if the string is empty

            if (string.IsNullOrEmpty(category))

                return new List<ProductInfo>();

 

            // Run a search against the data store

            return dal.GetProductsByCategory(category);

        }

3．采用ASP.NET 2.0 Membership来做认证和授权

4．创建了针对Oracle 10g 的Custom  ASP.NET 2.0 Membership Provider

5．利用ASP.NET 2.0的Custom Oracle 和 SQL Server Profile Providers 做用户状态管理，包括购物车等

6．采用了Master Pages，取代了原来的用户控件，来实现统一的界面效果

7．使用了ASP.NET 2.0 Wizard控件实现check-out

8．使用了SqlCacheDependency来实现数据库层次的缓存更新(cache invalidation)功能

9．使用了消息队列来实现异时订单处理。

 

2.整体架构：

数据库：(暂略)

项目列表：从整体可以看出，Pet Shop 4的项目体系已经很庞大，考虑的方面也较3.0更全面复杂。

 

序号	项目名称	描述
1	BLL	业务逻辑层
2	CacheDependencyFactory	缓存依赖类的工厂类
3	WEB	表示层
4	DALFactory	数据层的抽象工厂
5	DBUtility	数据访问类组件
6	IBLLStrategy	同步/异步策略接口
7	ICacheDependency	缓存依赖类接口
8	IDAL	数据访问层接口定义
9	IMessaging	异时处理消息队列接口定义
10	IProfileDAL	Profile的数据访问层接口定义
11	Membership	Membership认证和授权管理
12	MessagingFactory	异时处理消息队列的抽象工厂
13	Model	业务实体
14	MSMQMessaging	异时处理消息队列的实现
15	OracleDAL	Oracle数据访问层
16	OracleProfileDAL	Oracle的Profile Providers 做用户状态管理，包括购物车等
17	OrderProcessor	后台处理进程，处理订单队列
18	Profile	Profile的数据访问层
19	ProfileDALFactory	ProfileDAL的工厂类(反射创建ProfileDAL)
20	SQLProfileDAL	SQL Server 的Profile Providers 做用户状态管理，包括购物车等
21	SQLServerDAL	SQLServer数据访问层
22	TableCacheDependency	缓存依赖实现类

 

项目分解：

由于整体已经有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	后台处理进程，处理订单队列

 

 

 

3．Petshop 4中的设计模式：

工厂模式:

首当其冲的就是工厂模式，很容易就可以看出来，也是应用最多的。

DALFactory：数据访问层的抽象工厂（决定创建哪种数据库类型的数据访问层。可以选择：SQLServer，Oracle）

CacheDependencyFactory：缓存依赖类的工厂类。（创建具体表的缓存依赖）

MessagingFactory ：异时处理消息队列的抽象工厂（反射创建具体的异时处理类）

ProfileDALFactory：ProfileDAL的工厂类(反射选择创建Oracle 和SQL Server的 ProfileDAL)

 

策略模式: IorderStrategy

 

 

 

中介模式

CategoryDataProxy ItemDataProxy  ProductDataProxy

 

 

 

《解剖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模块，除了解除了向下的依赖之外，对于其上的业务逻辑层，同样仅存在弱依赖关系，如下图所示：

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

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

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

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

在图五中，各个层次中还引入了辅助的模块，如数据访问层的Messaging模块，是为异步插入订单的功能提供，采用了MSMQ（Microsoft Messaging Queue）技术。而表示层的CacheDependency则提供缓存功能。

转自