pet shop

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则提供缓存功能。

转自

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/soarheaven/archive/2007/04/17/1567945.aspx

 

PetShop 4.0使用了四个数据库，分别为：MSPetShop4 、MSPetShop4Orders 、MSPetShop4Profile
、MSPetShop4Services　　

一、MSPetShop4

其中MSPetShop4用来管理产品、分类等基本数据信息，其中共有六个表
　　AspNet_SqlCacheTablesForChangeNotification
　　Category
　　Inventory
　　Item

　　Product
　　Supplier 

    Category表产品分类表。这个分类主要对产品在大类别上进行分类，比如在petshop中，有鱼类，鸟类等。里面的字段的意思我想大家看得很明白，一个是分类ID，一个是类别名称，一个是他的描述，主键是分类ID。

    product表是产品表，这个产品并不是最终的产品，而是一个抽象意义上的产品，比如说鱼，有很多种类的鱼，比如鲨鱼等等，对于一个宠物商店，鲨鱼这个种类有好几个不同和名字的，那么摆在货架上的就是好几个不同的名字的。具体的每个名字的就要用item表来表示了。那么在product这张表中，他的字段是：产品ID，产品分类，产品名字，备注描述，此类产品对应的图片地址。在这张表中，以产品ID为主键，同时建立了四个索引：1.产品名称；2.分类ID；3.产品名称＋分类ID；4.产品ID＋产品名称＋分类ID。有关索引的相关知识，请查阅数据库方面的资料。

   item表是具体的宠物。每一种产品（product）都对应有一种或几种具体的item。在这张表中productID为其对应的产品，并在这个字段上建立外键约束。这个表的字段从上到下的意思分别为：宠物项ID，对应产品ID，宠物价格，unitCost是什么意思我还没搞清楚，供应商ID，状态（我只看到里面的数据为P，但不知道怎么样修改），宠物名字，宠物所对应的图片地址。在这张表里面，itemID为主键，productid、supplier为外键，也就是他们的值是product表和supplier表中的值，建立了一个大的索引：itemid+productID+ListPrice+Name。

    supplier表是供应商表。这张表的作用，我还没看到有多大，只是在这里标识每一种宠物的供应者是谁，在标准的petshop安装后，里面只有两条数据，那么现在我来介绍一下这张表里面的字段的意思。上图中标识主键的为供应商ID，以下分别为供应商名字，status里面的值为AC，我搞不太清楚代表什么意思，Addr1,Addr2想必大家一看就明白是什么意思了，city从字面意思也可以搞清楚，state是代表美国的哪一个州，zip为邮政编码，后面的是电话号码。

    Inventory是宠物的库存表。ItemID为宠物的ID，下面为库存的数目。我个人认为这里的ItemID应该做一个外键约束，但是petshop并没有做，我不知道这是什么原因。

    根据上面的数据库表，petshop抽象出几个数据实体类。让我们先来分析一下，上面的数据库中，一共有六张表，可以表示这么几个概念，分别是缓存，类别，产品（我不知道这么叫好不好），宠物信息，供应商，库存。可以做为数据实体的肯定要去除缓存，库存，因为缓存只是一个技术，库存则是宠物信息里面可以包含的一个属性，我认为，余下的都可以抽象或是说映射。但是petshop中只对类别，产品，宠物信息进行了抽象实体，没有供应商的具体类，究其原因，可能是因为在petshop中，供应商并不是一个主要的矛盾，也就是说宠物商店和供应商没有太大关系，所以没有包含。那么就让我们看一看在程序中是怎么样来抽象的。如下图所示：

　　

除AspNet_SqlCacheTablesForChangeNotification是为了配合.net的缓存处理外，其它表都是基本数据表，它们在PetShop 4.0中有对应的模型。　　

二、MSPetShop4Orders 　

分别主要用来存储订单明细、订单基本信息和订单状态的数据。

       LineItem 存储定单中购买商品的信息，例如：定单号，商品ID，单价，数量

       Orders 用于存储商品定单详细信息，例如：定单号，用户ID，联系信息等

       OrderStatus 用于记录定单状态

三、MSPetShop4Profile

MSPetShop4Profile 数据库说明

   主要存储账户基本信息、购物车信息和用户配置信息。

       Account 记录客户基本信息，例如：姓名，电子邮件地址，住址等。

       Cart  存储购物车和意象清单中的商品信息。

       Profiles 用于存储客户活动基本信息例如：用户名，是否匿名访问，上次登陆时间等

四、MSPetShop4Services

MSPetShop4Services 数据库说明

   存储成员资格，角色，用户配置，和应用程序等信息。

       aspnet_Applications 存储数据库所涉及应用程序有关信息。

       aspnet_Membership 存储与用户相关信息例如：用户登陆密码，创建时间。

       aspnet_Paths 存储应用程序和目录路径的对应关系数据。

       aspnet_PersonalizationAllUsers 存储针对所有用户的Web部件个性化设置信息。

       aspnet_PersonalizationPerUser 存储针对每个特定用户的Web部件个性化设置信息。

       aspnet_Profile 存储用户配置数据。

       aspnet_Roles 存储角色信息。

       aspnet_SchemaVersions 存储用户配置信息支持的模式。

       aspnet_Users 记录用户基本信息。

       aspnet_UsersInRoles 存储用户和角色的关系数据。

        aspnet_WebEvent_Events 存储Web事件相关信息。

　　通过将一个完整系统的数据按功能进行划分，各部分数据存储到独立的数据库服务器中，便是一种典型的分布式数据库模式。采用这种方式，不仅可以提高数据库以及应用的复用性，而且可以分散数据库服务器的压力，从而在某种程序上解决数据库瓶颈。