PetShop的系统架构设计

 

《解剖PetShop》系列

1、PetShop的系统架构设计

http://www.cnblogs.com/wayfarer/archive/2007/03/23/375382.html

2、PetShop数据访问层之数据库访问设计

http://www.cnblogs.com/wayfarer/archive/2006/04/21/381315.html

3、PetShop数据访问层之消息处理

http://www.cnblogs.com/wayfarer/archive/2007/03/15/496207.html

4、PetShop之ASP.NET缓存

http://www.cnblogs.com/wayfarer/archive/2006/11/01/547060.html

5、PetShop之业务逻辑层设计

http://www.cnblogs.com/wayfarer/archive/2006/11/05/550723.html

6、PetShop之表示层设计

http://www.cnblogs.com/wayfarer/archive/2006/11/11/557933.html

 

 

《解剖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中得到。

1、PetShop的系统架构设计

在软件体系架构设计中，分层式结构是最多见，也是最重要的一种结构。微软推荐的分层式结构通常分为三层，从下至上分别为：数据访问层、业务逻辑层（又或成为领域层）、表示层，如图所示：

图一：三层的分层式结构

数据访问层：有时候也称为是持久层，其功能主要是负责数据库的访问。简单的说法就是实现对数据表的Select，Insert，Update，Delete的操做。若是要加入ORM的元素，那么就会包括对象和数据表之间的mapping，以及对象实体的持久化。在PetShop的数据访问层中，并无使用ORM，从而致使了代码量的增长，能够看做是整个设计实现中的一大败笔。

业务逻辑层：是整个系统的核心，它与这个系统的业务（领域）有关。以PetShop为例，业务逻辑层的相关设计，均和网上宠物店特有的逻辑相关，例如查询宠物，下订单，添加宠物到购物车等等。若是涉及到数据库的访问，则调用数据访问层。

表示层：是系统的UI部分，负责使用者与整个系统的交互。在这一层中，理想的状态是不该包括系统的业务逻辑。表示层中的逻辑代码，仅与界面元素有关。在PetShop中，是利用ASP.Net来设计的，所以包含了许多Web控件和相关逻辑。

分层式结构究竟其优点何在？Martin Fowler在《Patterns of Enterprise Application Architecture》一书中给出了答案：
一、开发人员能够只关注整个结构中的其中某一层；
二、能够很容易的用新的实现来替换原有层次的实现；
三、能够下降层与层之间的依赖；
四、有利于标准化；
五、利于各层逻辑的复用。

归纳来讲，分层式设计能够达至以下目的：分散关注、松散耦合、逻辑复用、标准定义。

一个好的分层式结构，可使得开发人员的分工更加明确。一旦定义好各层次之间的接口，负责不一样逻辑设计的开发人员就能够分散关注，齐头并进。例如UI人员只需考虑用户界面的体验与操做，领域的设计人员能够仅关注业务逻辑的设计，而数据库设计人员也没必要为繁琐的用户交互而头疼了。每一个开发人员的任务获得了确认，开发进度就能够迅速的提升。

松散耦合的好处是显而易见的。若是一个系统没有分层，那么各自的逻辑都牢牢纠缠在一块儿，彼此间相互依赖，谁都是不可替换的。一旦发生改变，则牵一发而动全身，对项目的影响极为严重。下降层与层间的依赖性，既能够良好地保证将来的可扩展，在复用性上也是优点明显。每一个功能模块一旦定义好统一的接口，就能够被各个模块所调用，而不用为相同的功能进行重复地开发。

进行好的分层式结构设计，标准也是必不可少的。只有在必定程度的标准化基础上，这个系统才是可扩展的，可替换的。而层与层之间的通讯也必然保证了接口的标准化。

“金无足赤，人无完人”，分层式结构也不可避免具备一些缺陷：
一、下降了系统的性能。这是不言而喻的。若是不采用分层式结构，不少业务能够直接造访数据库，以此获取相应的数据，现在却必须经过中间层来完成。
二、有时会致使级联的修改。这种修改尤为体如今自上而下的方向。若是在表示层中须要增长一个功能，为保证其设计符合分层式结构，可能须要在相应的业务逻辑层和数据访问层中都增长相应的代码。

前面提到，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则提供缓存功能。这些特殊的模块，我会在此后的文章中详细介绍。

 

引用地址：http://www.cnblogs.com/wayfarer/archive/2006/04/14/375382.html