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

15 Comments »

1. 丫的每天都是技术文章，能不能搞点生活的 Comment by Samuel Chen — April 15, 2006 @ 10:08 pm
2. 您在文中提到”在PetShop的数据访问层中，并没有使用ORM，从而导致了代码量的增加，可以看作是整个设计实现中的一大败笔”,ORM(对象关系映射)
   如何减少代码，实现优雅的设计，能否试论一二？ Comment by Yan — April 16, 2006 @ 11:32 am
3. 如果使用IoC+O/R Mapping，不但各层之间的耦合降低到最小，而且持久层的代码也会大大精简。
   使用Spring.Net/Castle + NHibernate来重构一次，那么petshop将会真正的优雅起来。 Comment by abluedog — April 16, 2006 @ 4:32 pm
4. 不使用orm的话的确可以提高一些效率，对小型项目来说直接的数据库访问足矣，我的个人观点 Comment by NickLedson — April 16, 2006 @ 7:17 pm
5. @Samuel:
   没有办法啊，我的生活没有你的多姿多彩啊。呵呵:) 我同意abluedog和NickLedson的意见。 Comment by bruce zhang — April 17, 2006 @ 12:28 pm
6. 能不能介绍下PetShop4.0中的cache机制和MSMQ的机制? Comment by zdnet — April 20, 2006 @ 1:02 pm
7. 你有分析这个PetShop4的时间，还不如用spring.net+ORM重写一次，我看这个PetShop的设计没有多少值得我们学习的地方 Comment by abck — April 28, 2006 @ 2:43 pm
8. 版主一看就是一个技术渊博,集实践与理论于一身的高人,而且思维条理慎密,文笔流畅,佩服! 期待版主更多更好的文章.
   但是有些观点在下与你的看法稍有出入,先声明一下跟技术无关.
   那就是版主认为这里没有用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吧,而且借助一些代码生成器,这部分工作也不是那么恐怖. Comment by wangyihaier — May 6, 2006 @ 10:09 pm
9. 在.NET 2.0中TableAdapter可以帮助解决代码量大的问题 Comment by txd_lf — May 17, 2006 @ 1:52 pm
10. 请教一个问题，为什么要把IDAL设计成接口，而不是抽象类呢？ Comment by Anonymous — May 18, 2006 @ 5:03 pm
11. 请教一个问题，为什么要把IDAL设计成接口，而不是抽象类呢？ Comment by 小柯 — May 18, 2006 @ 5:04 pm
12. 我已经搞明白了，抽象类不能跨程序集，呵呵，实践出真知！ Comment by 小柯 — May 18, 2006 @ 5:43 pm
13. 我已经搞明白了，抽象类不能跨程序集，呵呵，实践出真知！ Comment by 小柯 — May 18, 2006 @ 5:43 pm 一语惊醒梦中人。 Comment by blackie — May 24, 2006 @ 11:19 am
14. 学习，学习。
    谢谢BRUCE Zhang 分享^-^ Comment by shmilyfly — May 30, 2006 @ 12:57 pm
15. 楼主对于分层式结构的“缺陷”描述是不太正确的。 1.分层式结构不一定会导致性能问题，相反，在一个结合了WorkUnit的系统中，还可能会提供系统的性能。性能问题主要取决于具体软件在分层架构中所采用的技术实现和机制，与分层架构本身是没有任何关系的 2.一个实现良好的分层结构并不会导致所谓的级联修改问题。对于一个业务层、表现层、数据访问层使用一一对应式的“蹩脚”实现，确实是会出现级联修改问题。但是这大多是因为实现者仍然是用分层结构形式来做他的两层系统。分层结构本身的三个层次在设计、逻辑、接口上的粒度是完全不同的，从设计角度上看根本不存在所谓级联问题，因为他的粗细颗粒不同，一个细粒度的DAC方法又怎么会导致一个粗粒度的BIZ方法的接口修改呢？表现层在实现良好的系统中往往会考虑模板化的数据显示（诸如XSLT等技术），这些表现技术也能很好的剥离业务逻辑、数据含义与表现层的耦合性，所以也不会出现级联修改问题

《解剖PetShop》系列之二二、PetShop数据访问层之数据库访问设计
在系列一中，我从整体上分析了PetShop的架构设计，并提及了分层的概念。从本部分开始，我将依次对各层进行代码级的分析，以求获得更加细致而深入的理解。在PetShop 4.0中，由于引入了ASP.Net 2.0的一些新特色，所以数据层的内容也更加的广泛和复杂，包括：数据库访问、Messaging、MemberShip、Profile四部分。在系列二中，我将介绍有关数据库访问的设计。在PetShop中，系统需要处理的数据库对象分为两类：一是数据实体，对应数据库中相应的数据表。它们没有行为，仅用于表现对象的数据。这些实体类都被放到Model程序集中，例如数据表Order对应的实体类OrderInfo，其类图如下： 这些对象并不具有持久化的功能，简单地说，它们是作为数据的载体，便于业务逻辑针对相应数据表进行读/写操作。虽然这些类的属性分别映射了数据表的列，而每一个对象实例也恰恰对应于数据表的每一行，但这些实体类却并不具备对应的数据库访问能力。由于数据访问层和业务逻辑层都将对这些数据实体进行操作，因此程序集Model会被这两层的模块所引用。第二类数据库对象则是数据的业务逻辑对象。这里所指的业务逻辑，并非业务逻辑层意义上的领域（domain）业务逻辑（从这个意义上，我更倾向于将业务逻辑层称为“领域逻辑层”），一般意义上说，这些业务逻辑即为基本的数据库操作，包括Select，Insert，Update和Delete。由于这些业务逻辑对象，仅具有行为而与数据无关，因此它们均被抽象为一个单独的接口模块IDAL，例如数据表Order对应的接口IOrder： 将数据实体与相关的数据库操作分离出来，符合面向对象的精神。首先，它体现了“职责分离”的原则。将数据实体与其行为分开，使得两者之间依赖减弱，当数据行为发生改变时，并不影响Model模块中的数据实体对象，避免了因一个类职责过多、过大，从而导致该类的引用者发生“灾难性”的影响。其次，它体现了“抽象”的精神，或者说是“面向接口编程”的最佳体现。抽象的接口模块IDAL，与具体的数据库访问实现完全隔离。这种与实现无关的设计，保证了系统的可扩展性，同时也保证了数据库的可移植性。在PetShop中，可以支持SQL Server和Oracle，那么它们具体的实现就分别放在两个不同的模块SQLServerDAL、OracleDAL中。以Order为例，在SQLServerDAL、OracleDAL两个模块中，有不同的实现，但它们同时又都实现了IOrder接口，如图： 从数据库的实现来看，PetShop体现出了没有ORM框架的臃肿与丑陋。由于要对数据表进行Insert和Select操作，以SQL Server为例，就使用了SqlCommand，SqlParameter，SqlDataReader等对象，以完成这些操作。尤其复杂的是Parameter的传递，在PetShop中，使用了大量的字符串常量来保存参数的名称。此外，PetShop还专门为SQL Server和Oracle提供了抽象的Helper类，包装了一些常用的操作，如ExecuteNonQuery、ExecuteReader等方法。在没有ORM的情况下，使用Helper类是一个比较好的策略，利用它来完成数据库基本操作的封装，可以减少很多和数据库操作有关的代码，这体现了对象复用的原则。PetShop将这些Helper类统一放到DBUtility模块中，不同数据库的Helper类暴露的方法基本相同，只除了一些特殊的要求，例如Oracle中处理bool类型的方式就和SQL Server不同，从而专门提供了OraBit和OraBool方法。此外，Helper类中的方法均为static方法，以利于调用。OracleHelper的类图如下： 对于数据访问层来说，最头疼的是SQL语句的处理。在早期的CS结构中，由于未采用三层式架构设计，数据访问层和业务逻辑层是紧密糅合在一起的，因此，SQL语句遍布与系统的每一个角落。这给程序的维护带来极大的困难。此外，由于Oracle使用的是PL-SQL，而SQL Server和Sybase等使用的是T-SQL，两者虽然都遵循了标准SQL的语法，但在很多细节上仍有区别，如果将SQL语句大量的使用到程序中，无疑为可能的数据库移植也带来了困难。最好的方法是采用存储过程。这种方法使得程序更加整洁，此外，由于存储过程可以以数据库脚本的形式存在，也便于移植和修改。但这种方式仍然有缺陷。一是存储过程的测试相对困难。虽然有相应的调试工具，但比起对代码的调试而言，仍然比较复杂且不方便。二是对系统的更新带来障碍。如果数据库访问是由程序完成，在.Net平台下，我们仅需要在修改程序后，将重新编译的程序集xcopy到部署的服务器上即可。如果使用了存储过程，出于安全的考虑，必须有专门的DBA重新运行存储过程的脚本，部署的方式受到了限制。我曾经在一个项目中，利用一个专门的表来存放SQL语句。如要使用相关的SQL语句，就利用关键字搜索获得对应语句。这种做法近似于存储过程的调用，但却避免了部署上的问题。然而这种方式却在性能上无法得到保证。它仅适合于SQL语句较少的场景。不过，利用良好的设计，我们可以为各种业务提供不同的表来存放SQL语句。同样的道理，这些SQL语句也可以存放到XML文件中，更有利于系统的扩展或修改。不过前提是，我们需要为它提供专门的SQL语句管理工具。SQL语句的使用无法避免，如何更好的应用SQL语句也无定论，但有一个原则值得我们遵守，就是“应该尽量让SQL语句尽存在于数据访问层的具体实现中”。当然，如果应用ORM，那么一切就变得不同了。因为ORM框架已经为数据访问提供了基本的Select，Insert，Update和Delete操作了。例如在NHibernate中，我们可以直接调用ISession对象的Save方法，来Insert（或者说是Create）一个数据实体对象：
public void Insert(OrderInfo order)
{
ISession s = Sessions.GetSession();
ITransaction trans = null;
try
{
trans = s.BeginTransaction();
s.Save( order);
trans.Commit();
}
finally
{
s.Close();
}
}没有SQL语句，也没有那些烦人的Parameters，甚至不需要专门去考虑事务。此外，这样的设计，也是与数据库无关的，NHibernate可以通过Dialect（方言）的机制支持不同的数据库。唯一要做的是，我们需要为OrderInfo定义hbm文件。当然，ORM框架并非是万能的，面对纷繁复杂的业务逻辑，它并不能完全消灭SQL语句，以及替代复杂的数据库访问逻辑，但它却很好的体现了“80/20（或90/10）法则”（也被称为“帕累托法则”），也就是说：花比较少（10%-20%）的力气就可以解决大部分（80%-90%）的问题，而要解决剩下的少部分问题则需要多得多的努力。至少，那些在数据访问层中占据了绝大部分的CRUD操作，通过利用ORM框架，我们就仅需要付出极少数时间和精力来解决它们了。这无疑缩短了整个项目开发的周期。还是回到对PetShop的讨论上来。现在我们已经有了数据实体，数据对象的抽象接口和实现，可以说有关数据库访问的主体就已经完成了。留待我们的还有两个问题需要解决：
1、数据对象创建的管理
2、利于数据库的移植在PetShop中，要创建的数据对象包括Order，Product，Category，Inventory，Item。在前面的设计中，这些对象已经被抽象为对应的接口，而其实现则根据数据库的不同而有所不同。也就是说，创建的对象有多种类别，而每种类别又有不同的实现，这是典型的抽象工厂模式的应用场景。而上面所述的两个问题，也都可以通过抽象工厂模式来解决。标准的抽象工厂模式类图如下： 例如，创建SQL Server的Order对象如下：
PetShopFactory factory = new SQLServerFactory();
IOrder = factory.CreateOrder();要考虑到数据库的可移植性，则factory必须作为一个全局变量，并在主程序运行时被实例化。但这样的设计虽然已经达到了“封装变化”的目的，但在创建PetShopFactory对象时，仍不可避免的出现了具体的类SQLServerFactory，也即是说，程序在这个层面上产生了与SQLServerFactory的强依赖。一旦整个系统要求支持Oracle，那么还需要修改这行代码为：
PetShopFactory factory = new OracleFactory();修改代码的这种行为显然是不可接受的。解决的办法是“依赖注入”。“依赖注入”的功能通常是用专门的IoC容器提供的，在Java平台下，这样的容器包括Spring，PicoContainer等。而在.Net平台下，最常见的则是Spring.Net。不过，在PetShop系统中，并不需要专门的容器来实现“依赖注入”，简单的做法还是利用配置文件和反射功能来实现。也就是说，我们可以在web.config文件中，配置好具体的Factory对象的完整的类名。然而，当我们利用配置文件和反射功能时，具体工厂的创建就显得有些“画蛇添足”了，我们完全可以在配置文件中，直接指向具体的数据库对象实现类，例如PetShop.SQLServerDAL.IOrder。那么，抽象工厂模式中的相关工厂就可以简化为一个工厂类了，所以我将这种模式称之为“具有简单工厂特质的抽象工厂模式”，其类图如下： DataAccess类完全取代了前面创建的工厂类体系，它是一个sealed类，其中创建各种数据对象的方法，均为静态方法。之所以能用这个类达到抽象工厂的目的，是因为配置文件和反射的运用，如下的代码片断所示：
public sealed class DataAccess
{
// Look up the DAL implementation we should be using
private static readonly string path = ConfigurationManager.AppSettings[”WebDAL”];
private static readonly string orderPath = ConfigurationManager.AppSettings[”OrdersDAL”]; public static PetShop.IDAL.IOrder CreateOrder()
{
string className = orderPath + “.Order”;
return (PetShop.IDAL.IOrder)Assembly.Load(orderPath).CreateInstance(className);
}
}在PetShop中，这种依赖配置文件和反射创建对象的方式极其常见，包括IBLLStategy、CacheDependencyFactory等等。这些实现逻辑散布于整个PetShop系统中，在我看来，是可以在此基础上进行重构的。也就是说，我们可以为整个系统提供类似于“Service Locator”的实现：
public static class ServiceLocator
{
private static readonly string dalPath = ConfigurationManager.AppSettings[”WebDAL”];
private static readonly string orderPath = ConfigurationManager.AppSettings[”OrdersDAL”];
//……
private static readonly string orderStategyPath = ConfigurationManager.AppSettings[”OrderStrategyAssembly”]; public static object LocateDALObject(string className)
{
string fullPath = dalPath + “.” + className;
return Assembly.Load(dalPath).CreateInstance(fullPath);
}
public static object LocateDALOrderObject(string className)
{
string fullPath = orderPath + “.” + className;
return Assembly.Load(orderPath).CreateInstance(fullPath);
}
public static object LocateOrderStrategyObject(string className)
{
string fullPath = orderStategyPath + “.” + className;
return Assembly.Load(orderStategyPath).CreateInstance(fullPath);
}
//……
}那么和所谓“依赖注入”相关的代码都可以利用ServiceLocator来完成。例如类DataAccess就可以简化为：
public sealed class DataAccess
{
public static PetShop.IDAL.IOrder CreateOrder()
{
return (PetShop.IDAL.IOrder)ServiceLocator. LocateDALOrderObject(”Order”);
}
}通过ServiceLocator，将所有与配置文件相关的namespace值统一管理起来，这有利于各种动态创建对象的管理和未来的维护。 三、PetShop数据访问层之消息处理 在进行系统设计时，除了对安全、事务等问题给与足够的重视外，性能也是一个不可避免的问题所在，尤其是一个B/S结构的软件系统，必须充分地考虑访问量、数据流量、服务器负荷的问题。解决性能的瓶颈，除了对硬件系统进行升级外，软件设计的合理性尤为重要。
在前面我曾提到，分层式结构设计可能会在一定程度上影响数据访问的性能，然而与它给设计人员带来的好处相比，几乎可以忽略。要提供整个系统的性能，还可以从数据库的优化着手，例如连接池的使用、建立索引、优化查询策略等等，例如在PetShop中就利用了数据库的Cache，对于数据量较大的订单数据，则利用分库的方式为其单独建立了Order和Inventory数据库。而在软件设计上，比较有用的方式是利用多线程与异步处理方式。
在PetShop4.0中，使用了Microsoft Messaging Queue(MSMQ)技术来完成异步处理，利用消息队列临时存放要插入的数据，使得数据访问因为不需要访问数据库从而提供了访问性能，至于队列中的数据，则等待系统空闲的时候再进行处理，将其最终插入到数据库中。
PetShop4.0中的消息处理，主要分为如下几部分：消息接口IMessaging、消息工厂MessagingFactory、MSMQ实现MSMQMessaging以及数据后台处理应用程序OrderProcessor。
从模块化分上，PetShop自始自终地履行了“面向接口设计”的原则，将消息处理的接口与实现分开，并通过工厂模式封装消息实现对象的创建，以达到松散耦合的目的。
由于在PetShop中仅对订单的处理使用了异步处理方式，因此在消息接口IMessaging中，仅定义了一个IOrder接口，其类图如下： 在对消息接口的实现中，考虑到未来的扩展中会有其他的数据对象会使用MSMQ，因此定义了一个Queue的基类，实现消息Receive和Send的基本操作：
public virtual object Receive()
{
try
{
using (Message message = queue.Receive(timeout, transactionType))
return message;
}
catch (MessageQueueException mqex)
{
if (mqex.MessageQueueErrorCode == MessageQueueErrorCode.IOTimeout)
throw new TimeoutException();
throw;
}
}
public virtual void Send(object msg)
{
queue.Send(msg, transactionType);
}
其中queue对象是System.Messaging.MessageQueue类型，作为存放数据的队列。MSMQ队列是一个可持久的队列，因此不必担心用户不间断地下订单会导致订单数据的丢失。在PetShopQueue设置了timeout值，OrderProcessor会根据timeout值定期扫描队列中的订单数据。
MSMQMessaging模块中，Order对象实现了IMessaging模块中定义的接口IOrder，同时它还继承了基类PetShopQueue，其定义如下：
public class Order:PetShopQueue, PetShop.IMessaging.IOrder
方法的实现代码如下：
public new OrderInfo Receive()
{
// This method involves in distributed transaction and need Automatic Transaction type
base.transactionType = MessageQueueTransactionType.Automatic;
return (OrderInfo)((Message)base.Receive()).Body;
} public OrderInfo Receive(int timeout)
{
base.timeout = TimeSpan.FromSeconds(Convert.ToDouble(timeout));
return Receive();
} public void Send(OrderInfo orderMessage)
{
// This method does not involve in distributed transaction and optimizes performance using Single type
base.transactionType = MessageQueueTransactionType.Single;
base.Send(orderMessage);
}
所以，最后的类图应该如下： 注意在Order类的Receive()方法中，是用new关键字而不是override关键字来重写其父类PetShopQueue的Receive()虚方法。因此，如果是实例化如下的对象，将会调用PetShopQueue的Receive()方法，而不是子类Order的Receive()方法：
PetShopQueue queue = new Order();
queue.Receive();
从设计上来看，由于PetShop采用“面向接口设计”的原则，如果我们要创建Order对象，应该采用如下的方式：
IOrder order = new Order();
order.Receive();
考虑到IOrder的实现有可能的变化，PetShop仍然利用了工厂模式，将IOrder对象的创建用专门的工厂模块进行了封装： 在类QueueAccess中，通过CreateOrder()方法利用反射技术创建正确的IOrder类型对象：
public static PetShop.IMessaging.IOrder CreateOrder()
{
string className = path + “.Order”;
return PetShop.IMessaging.IOrder)Assembly.Load(path).CreateInstance(className);
}
path的值通过配置文件获取：
private static readonly string path = ConfigurationManager.AppSettings[”OrderMessaging”];
而配置文件中，OrderMessaging的值设置如下：

之所以利用工厂模式来负责对象的创建，是便于在业务层中对其调用，例如在BLL模块中OrderAsynchronous类：
public class OrderAsynchronous : IOrderStrategy
{
private static readonly PetShop.IMessaging.IOrder asynchOrder = PetShop.MessagingFactory.QueueAccess.CreateOrder();
public void Insert(PetShop.Model.OrderInfo order)
{
asynchOrder.Send(order);
}
}
一旦IOrder接口的实现发生变化，这种实现方式就可以使得客户仅需要修改配置文件，而不需要修改代码，如此就可以避免程序集的重新编译和部署，使得系统能够灵活应对需求的改变。例如定义一个实现IOrder接口的SpecialOrder，则可以新增一个模块，如PetShop.SpecialMSMQMessaging，而类名则仍然为Order，那么此时我们仅需要修改配置文件中OrderMessaging的值即可：

OrderProcessor是一个控制台应用程序，不过可以根据需求将其设计为Windows Service。它的目的就是接收消息队列中的订单数据，然后将其插入到Order和Inventory数据库中。它利用了多线程技术，以达到提高系统性能的目的。
在OrderProcessor应用程序中，主函数Main用于控制线程，而核心的执行任务则由方法ProcessOrders()实现：
private static void ProcessOrders()
{
// the transaction timeout should be long enough to handle all of orders in the batch
TimeSpan tsTimeout = TimeSpan.FromSeconds(Convert.ToDouble(transactionTimeout * batchSize)); Order order = new Order();
while (true)
{
// queue timeout variables
TimeSpan datetimeStarting = new TimeSpan(DateTime.Now.Ticks);
double elapsedTime = 0; int processedItems = 0; ArrayList queueOrders = new ArrayList(); using (TransactionScope ts = new TransactionScope(TransactionScopeOption.Required, tsTimeout))
{
// Receive the orders from the queue
for (int j = 0; j < batchSize; j++)
{
try
{
//only receive more queued orders if there is enough time
if ((elapsedTime + queueTimeout + transactionTimeout) < tsTimeout.TotalSeconds)
{
queueOrders.Add(order.ReceiveFromQueue(queueTimeout));
}
else
{
j = batchSize; // exit loop
} //update elapsed time
elapsedTime = new TimeSpan(DateTime.Now.Ticks).TotalSeconds - datetimeStarting.TotalSeconds;
}
catch (TimeoutException)
{
//exit loop because no more messages are waiting
j = batchSize;
}
}
//process the queued orders
for (int k = 0; k < queueOrders.Count; k++)
{
order.Insert((OrderInfo)queueOrders[k]);
processedItems++;
totalOrdersProcessed++;
} //batch complete or MSMQ receive timed out
ts.Complete();
} Console.WriteLine("(Thread Id " + Thread.CurrentThread.ManagedThreadId + ") batch finished, " + processedItems + " items, in " + elapsedTime.ToString() + " seconds.");
}
}
首先，它会通过PetShop.BLL.Order类的公共方法ReceiveFromQueue()来获取消息队列中的订单数据，并将其放入到一个ArrayList对象中，然而再调用PetShop.BLL.Order类的Insert方法将其插入到Order和Inventory数据库中。
在PetShop.BLL.Order类中，并不是直接执行插入订单的操作，而是调用了IOrderStrategy接口的Insert()方法：
public void Insert(OrderInfo order)
{
// Call credit card procesor
ProcessCreditCard(order); // Insert the order (a)synchrounously based on configuration
orderInsertStrategy.Insert(order);
}
在这里，运用了一个策略模式，类图如下所示： 在PetShop.BLL.Order类中，仍然利用配置文件来动态创建IOrderStategy对象：
private static readonly PetShop.IBLLStrategy.IOrderStrategy orderInsertStrategy = LoadInsertStrategy();
private static PetShop.IBLLStrategy.IOrderStrategy LoadInsertStrategy()
{
// Look up which strategy to use from config file
string path = ConfigurationManager.AppSettings[”OrderStrategyAssembly”];
string className = ConfigurationManager.AppSettings[”OrderStrategyClass”]; // Using the evidence given in the config file load the appropriate assembly and class
return (PetShop.IBLLStrategy.IOrderStrategy)Assembly.Load(path).CreateInstance(className);
}
由于OrderProcessor是一个单独的应用程序，因此它使用的配置文件与PetShop不同，是存放在应用程序的App.config文件中，在该文件中，对IOrderStategy的配置为：


因此，以异步方式插入订单的流程如下图所示： Microsoft Messaging Queue(MSMQ)技术除用于异步处理以外，它主要还是一种分布式处理技术。分布式处理中，一个重要的技术要素就是有关消息的处理，而在System.Messaging命名空间中，已经提供了Message类，可以用于承载消息的传递，前提上消息的发送方与接收方在数据定义上应有统一的接口规范。
MSMQ在分布式处理的运用，在我参与的项目中已经有了实现。在为一个汽车制造商开发一个大型系统时，分销商Dealer作为.Net客户端，需要将数据传递到管理中心，并且该数据将被Oracle的EBS(E-Business System)使用。由于分销商管理系统（DMS）采用的是C/S结构，数据库为SQL Server，而汽车制造商管理中心的EBS数据库为Oracle。这里就涉及到两个系统之间数据的传递。
实现架构如下： 首先Dealer的数据通过MSMQ传递到MSMQ Server，此时可以将数据插入到SQL Server数据库中，同时利用FTP将数据传送到专门的文件服务器上。然后利用IBM的EAI技术（企业应用集成，Enterprise Application Itegration）定期将文件服务器中的文件，利用接口规范写入到EAI数据库服务器中，并最终写道EBS的Oracle数据库中。
上述架构是一个典型的分布式处理结构，而技术实现的核心就是MSMQ和EAI。由于我们已经定义了统一的接口规范，在通过消息队列形成文件后，此时的数据就已经与平台无关了，使得在.Net平台下的分销商管理系统能够与Oracle的EBS集成起来，完成数据的处理。