本文深入分析了微软PetShop 4.0的系统架构设计，包括其三层架构（数据访问层、业务逻辑层、表示层）及各层间的职责划分。特别介绍了PetShop 4.0中如何通过接口实现数据访问层的抽象，以及在业务逻辑层中应用抽象原则提升灵活性。
PetShop的系统架构设计
《解剖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则提供缓存功能。这些特殊的模块，我会在此后的文章中详细介绍。
扫一扫
874
到【灌水乐园】发言
丫的每天都是技术文章，能不能搞点生活的
Comment by Samuel Chen — April 15, 2006 @ 10:08 pm
您在文中提到”在PetShop的数据访问层中，并没有使用ORM，从而导致了代码量的增加，可以看作是整个设计实现中的一大败笔”,ORM(对象关系映射)
如何减少代码，实现优雅的设计，能否试论一二？
Comment by Yan — April 16, 2006 @ 11:32 am
如果使用IoC+O/R Mapping，不但各层之间的耦合降低到最小，而且持久层的代码也会大大精简。
使用Spring.Net/Castle + NHibernate来重构一次，那么petshop将会真正的优雅起来。
Comment by abluedog — April 16, 2006 @ 4:32 pm
不使用orm的话的确可以提高一些效率，对小型项目来说直接的数据库访问足矣，我的个人观点
Comment by NickLedson — April 16, 2006 @ 7:17 pm
@Samuel:
没有办法啊，我的生活没有你的多姿多彩啊。呵呵:)
我同意abluedog和NickLedson的意见。
Comment by bruce zhang — April 17, 2006 @ 12:28 pm
能不能介绍下PetShop4.0中的cache机制和MSMQ的机制?
Comment by zdnet — April 20, 2006 @ 1:02 pm
你有分析这个PetShop4的时间，还不如用spring.net+ORM重写一次，我看这个PetShop的设计没有多少值得我们学习的地方
Comment by abck — April 28, 2006 @ 2:43 pm
版主一看就是一个技术渊博,集实践与理论于一身的高人,而且思维条理慎密,文笔流畅,佩服! 期待版主更多更好的文章.
但是有些观点在下与你的看法稍有出入,先声明一下跟技术无关.
那就是版主认为这里没有用ORM是一个败笔,我却不这样认为.
1.首先引用版主的前言”PetShop是一个范例，微软用它来展示.Net企业系统开发的能力。业界有许多.Net与J2EE之争，许多数据是从微软的PetShop和Sun的PetStore而来。这种争论不可避免带有浓厚的商业色彩”. 的确这是当时微软欲从java手中抢夺市场做的抄作,从先进技术而言,就像人的手掌,五指代表不不同的技术,当你沿着手指往下走的终点是都会到掌心.而且无论从技术架构到oo观念的运用,java可以说已经做到了极至. 微软唯一能比拟的在当时就是想在他的performance方面做文章.所以,从这个角度来讲,他决不可能用orm的. 我本人套用这个架构曾试图将orm放进去,但是performance差了一大截,尤其是压力测试.
2.我认为在2.0中,如果将来都用sql2005, 可能已经不再需要用hibernate等orm了,本身sql2005当中的相当大的部分就是参照了hibernate的思想的,所以有必要的话,微软可能有一天在出一版的petshop就用他的sql2005的特性,也不是不可能,不过可能要等到微软对自己的sql2005的性能和稳定性到达一个信心程度后,再看吧:)
所以,以在下愚见,如果自身项目对于performance有很高要求的话,就费点累多写些code吧,而且借助一些代码生成器,这部分工作也不是那么恐怖.
评论
是使用的摘要方式，不过刚才忘了打勾，现在改过来了。你反应还挺快的。
回复
2.0的，
知道的请回，
谢谢， 回复
相信很多人都研究过PetShop和Dawamish,但写出有深度的系统化的研究文章的人不多.
所以非常感谢,甚至有点崇拜了!
不知道Dawamish有没有.NET2.0版的. 回复
感谢楼主奉献一篇好文 回复
# re: PetShop的系统架构设计 2006-04-14 18:45 秋雨飘飞
结构清晰,把复杂的问题写得如此有条理.
petshop4是前两天下的,看了两天就乱了两天.看到此文问题都解决了! 回复
请教一个问题:在MemberShip里对于自定义字段是有什么好的方法操作.在petshop4里好像是没有用到! 回复
我认为Ｍ＄并没有在这方面下力气，他们的目标应该就是快速开发
至于怎样把项目做的可靠，可维护，可用，可扩展
他们关注的较少！ 回复
看看微软的 LINQ项目就清楚,Ｍ＄在这方面下大力气.
回复
（1）在业务逻辑层中，不存在orders和items，应该改为order，item
（2）在数据访问层中，不仅仅是Inventory、Orders Data Access。这里还包括Category、Item、Product。因此，应该改为Item、Order etc. Data Access
回复
# re: PetShop的系统架构设计问题 2006-07-17 23:51 zhh
2.用petshop4目录中的Build.bat编译后网站可以运行
问题是：在visual web developer 2005中除web可用外，其它如BLL,CachedependencyFactory,DALFactory等均显示不可用，所有在上述目录中的.cs文件在visual web developer 2005中也都无法看见，如何解决？ 回复