在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。微软推荐的分层式结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层（又或成为领域层）、表示层，如图所示：
数据访问层：有时候也称为是持久层，其功能主要是负责数据库的访问。简单的说法就是实现对数据表的Select，Insert，Update，Delete的操作。如果要加入ORM的元素，那么就会包括对象和数据表之间的mapping，以及对象实体的持久化。在PetShop的数据访问层中，并没有使用ORM，从而导致了代码量的增加，可以看作是整个设计实现中的一大败笔。
松散耦合的好处是显而易见的。如果一个系统没有分层，那么各自的逻辑都紧紧纠缠在一起，彼此间相互依赖，谁都是不可替换的。一旦发生改变，则牵一发而动全身，对项目的影响极为严重。降低层与层间的依赖性，既可以良好地保证未来的可扩展，在复用性上也是优势明显。每个功能模块一旦定义好统一的接口，就可以被各个模块所调用，而不用为相同的功能进行重复地开发。
进行好的分层式结构设计，标准也是必不可少的。只有在一定程度的标准化基础上，这个系统才是可扩展的，可替换的。而层与层之间的通信也必然保证了接口的标准化。
“金无足赤，人无完人”，分层式结构也不可避免具有一些缺陷：1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。
前面提到，PetShop的表示层是用ASP.Net设计的，也就是说，它应是一个BS系统。在.Net中，标准的BS分层式结构如下图所示：
随着PetShop版本的更新，其分层式结构也在不断的完善，例如PetShop2.0，就没有采用标准的三层式结构，如图三：
从图中我们可以看到，并没有明显的数据访问层设计。这样的设计虽然提高了数据访问的性能，但也同时导致了业务逻辑层与数据访问的职责混乱。一旦要求支持的数据库发生变化，或者需要修改数据访问的逻辑，由于没有清晰的分层，会导致项目作大的修改。而随着硬件系统性能的提高，以及充分利用缓存、异步处理等机制，分层式结构所带来的性能影响几乎可以忽略不计。
PetShop3.0纠正了此前层次不明的问题，将数据访问逻辑作为单独的一层独立出来：
PetShop4.0基本上延续了3.0的结构，但在性能上作了一定的改进，引入了缓存和异步处理机制，同时又充分利用了ASP.Net2.0的新功能MemberShip，因此PetShop4.0的系统架构图如下所示：
比较3.0和4.0的系统架构图，其核心的内容并没有发生变化。在数据访问层（DAL）中，仍然采用DALInterface抽象出数据访问逻辑，并以DALFactory作为数据访问层对象的工厂模块。对于DALInterface而言，分别有支持MS-SQL的SQLServerDAL和支持Oracle的OracleDAL具体实现。而Model模块则包含了数据实体对象。其详细的模块结构图如下所示：
可以看到，在数据访问层中，完全采用了“面向接口编程”思想。抽象出来的IDAL模块，脱离了与具体数据库的依赖，从而使得整个数据访问层利于数据库迁移。DALFactory模块专门管理DAL对象的创建，便于业务逻辑层访问。SQLServerDAL和OracleDAL模块均实现IDAL模块的接口，其中包含的逻辑就是对数据库的Select，Insert，Update和Delete操作。因为数据库类型的不同，对数据库的操作也有所不同，代码也会因此有所区别。
此外，抽象出来的IDAL模块，除了解除了向下的依赖之外，对于其上的业务逻辑层，同样仅存在弱依赖关系，如下图所示：
图七中BLL是业务逻辑层的核心模块，它包含了整个系统的核心业务。在业务逻辑层中，不能直接访问数据库，而必须通过数据访问层。注意图中对数据访问业务的调用，是通过接口模块IDAL来完成的。既然与具体的数据访问逻辑无关，则层与层之间的关系就是松散耦合的。如果此时需要修改数据访问层的具体实现，只要不涉及到IDAL的接口定义，那么业务逻辑层就不会受到任何影响。毕竟，具体实现的SQLServerDAL和OracalDAL根本就与业务逻辑层没有半点关系。
因为在PetShop4.0中引入了异步处理机制。插入订单的策略可以分为同步和异步，两者的插入策略明显不同，但对于调用者而言，插入订单的接口是完全一样的，所以PetShop4.0中设计了IBLLStrategy模块。虽然在IBLLStrategy模块中，仅仅是简单的IOrderStategy，但同时也给出了一个范例和信息，那就是在业务逻辑的处理中，如果存在业务操作的多样化，或者是今后可能的变化，均应利用抽象的原理。或者使用接口，或者使用抽象类，从而脱离对具体业务的依赖。不过在PetShop中，由于业务逻辑相对简单，这种思想体现得不够明显。也正因为此，PetShop将核心的业务逻辑都放到了一个模块BLL中，并没有将具体的实现和抽象严格的按照模块分开。所以表示层和业务逻辑层之间的调用关系，其耦合度相对较高：
在图五中，各个层次中还引入了辅助的模块，如数据访问层的Messaging模块，是为异步插入订单的功能提供，采用了MSMQ（MicrosoftMessagingQueue）技术。而表示层的CacheDependency则提供缓存功能。
二、PetShop数据访问层之数据库访问设计在系列一中，我从整体上分析了PetShop的架构设计，并提及了分层的概念。从本部分开始，我将依次对各层进行代码级的分析，以求获得更加细致而深入的理解。在PetShop4.0中，由于引入了ASP.Net2.0的一些新特色，所以数据层的内容也更加的广泛和复杂，包括：数据库访问、Messaging、MemberShip、Profile四部分。在系列二中，我将介绍有关数据库访问的设计。
在PetShop中，系统需要处理的数据库对象分为两类：一是数据实体，对应数据库中相应的数据表。它们没有行为，仅用于表现对象的数据。这些实体类都被放到Model程序集中，例如数据表Order对应的实体类OrderInfo，其类图如下：
这些对象并不具有持久化的功能，简单地说，它们是作为数据的载体，便于业务逻辑针对相应数据表进行读/写操作。虽然这些类的属性分别映射了数据表的列，而每一个对象实例也恰恰对应于数据表的每一行，但这些实体类却并不具备对应的数据库访问能力。
由于数据访问层和业务逻辑层都将对这些数据实体进行操作，因此程序集Model会被这两层的模块所引用。
第二类数据库对象则是数据的业务逻辑对象。这里所指的业务逻辑，并非业务逻辑层意义上的领域（domain）业务逻辑（从这个意义上，我更倾向于将业务逻辑层称为“领域逻辑层”），一般意义上说，这些业务逻辑即为基本的数据库操作，包括Select，Insert，Update和Delete。由于这些业务逻辑对象，仅具有行为而与数据无关，因此它们均被抽象为一个单独的接口模块IDAL，例如数据表Order对应的接口IOrder：
以Order为例，在SQLServerDAL、OracleDAL两个模块中，有不同的实现，但它们同时又都实现了IOrder接口，如图：
从数据库的实现来看，PetShop体现出了没有ORM框架的臃肿与丑陋。由于要对数据表进行Insert和Select操作，以SQLServer为例，就使用了SqlCommand，SqlParameter，SqlDataReader等对象，以完成这些操作。尤其复杂的是Parameter的传递，在PetShop中，使用了大量的字符串常量来保存参数的名称。此外，PetShop还专门为SQLServer和Oracle提供了抽象的Helper类，包装了一些常用的操作，如ExecuteNonQuery、ExecuteReader等方法。
在没有ORM的情况下，使用Helper类是一个比较好的策略，利用它来完成数据库基本操作的封装，可以减少很多和数据库操作有关的代码，这体现了对象复用的原则。PetShop将这些Helper类统一放到DBUtility模块中，不同数据库的Helper类暴露的方法基本相同，只除了一些特殊的要求，例如Oracle中处理bool类型的方式就和SQLServer不同，从而专门提供了OraBit和OraBool方法。此外，Helper类中的方法均为static方法，以利于调用。OracleHelper的类图如下：
对于数据访问层来说，最头疼的是SQL语句的处理。在早期的CS结构中，由于未采用三层式架构设计，数据访问层和业务逻辑层是紧密糅合在一起的，因此，SQL语句遍布与系统的每一个角落。这给程序的维护带来极大的困难。此外，由于Oracle使用的是PL-SQL，而SQLServer和Sybase等使用的是T-SQL，两者虽然都遵循了标准SQL的语法，但在很多细节上仍有区别，如果将SQL语句大量的使用到程序中，无疑为可能的数据库移植也带来了困难。
最好的方法是采用存储过程。这种方法使得程序更加整洁，此外，由于存储过程可以以数据库脚本的形式存在，也便于移植和修改。但这种方式仍然有缺陷。一是存储过程的测试相对困难。虽然有相应的调试工具，但比起对代码的调试而言，仍然比较复杂且不方便。二是对系统的更新带来障碍。如果数据库访问是由程序完成，在.Net平台下，我们仅需要在修改程序后，将重新编译的程序集xcopy到部署的服务器上即可。如果使用了存储过程，出于安全的考虑，必须有专门的DBA重新运行存储过程的脚本，部署的方式受到了限制。
SQL语句的使用无法避免，如何更好的应用SQL语句也无定论，但有一个原则值得我们遵守，就是“应该尽量让SQL语句尽存在于数据访问层的具体实现中”。
当然，如果应用ORM，那么一切就变得不同了。因为ORM框架已经为数据访问提供了基本的Select，Insert，Update和Delete操作了。例如在NHibernate中，我们可以直接调用ISession对象的Save方法，来Insert（或者说是Create）一个数据实体对象：publicvoidInsert(OrderInfoorder){ISessions=Sessions.GetSession();ITransactiontrans=null;try{trans=s.BeginTransaction();s.Save(order);trans.Commit();}finally{s.Close();}}
没有SQL语句，也没有那些烦人的Parameters，甚至不需要专门去考虑事务。此外，这样的设计，也是与数据库无关的，NHibernate可以通过Dialect（方言）的机制支持不同的数据库。唯一要做的是，我们需要为OrderInfo定义hbm文件。
还是回到对PetShop的讨论上来。现在我们已经有了数据实体，数据对象的抽象接口和实现，可以说有关数据库访问的主体就已经完成了。留待我们的还有两个问题需要解决：1、数据对象创建的管理2、利于数据库的移植
在PetShop中，要创建的数据对象包括Order，Product，Category，Inventory，Item。在前面的设计中，这些对象已经被抽象为对应的接口，而其实现则根据数据库的不同而有所不同。也就是说，创建的对象有多种类别，而每种类别又有不同的实现，这是典型的抽象工厂模式的应用场景。而上面所述的两个问题，也都可以通过抽象工厂模式来解决。标准的抽象工厂模式类图如下：
例如，创建SQLServer的Order对象如下：PetShopFactoryfactory=newSQLServerFactory();IOrder=factory.CreateOrder();
要考虑到数据库的可移植性，则factory必须作为一个全局变量，并在主程序运行时被实例化。但这样的设计虽然已经达到了“封装变化”的目的，但在创建PetShopFactory对象时，仍不可避免的出现了具体的类SQLServerFactory，也即是说，程序在这个层面上产生了与SQLServerFactory的强依赖。一旦整个系统要求支持Oracle，那么还需要修改这行代码为：PetShopFactoryfactory=newOracleFactory();
DataAccess类完全取代了前面创建的工厂类体系，它是一个sealed类，其中创建各种数据对象的方法，均为静态方法。之所以能用这个类达到抽象工厂的目的，是因为配置文件和反射的运用，如下的代码片断所示：publicsealedclassDataAccess{//LookuptheDALimplementationweshouldbeusingprivatestaticreadonlystringpath=ConfigurationManager.AppSettings["WebDAL"];privatestaticreadonlystringorderPath=ConfigurationManager.AppSettings["OrdersDAL"];
publicstaticPetShop.IDAL.IOrderCreateOrder(){stringclassName=orderPath+".Order";return(PetShop.IDAL.IOrder)Assembly.Load(orderPath).CreateInstance(className);}}
在PetShop中，这种依赖配置文件和反射创建对象的方式极其常见，包括IBLLStategy、CacheDependencyFactory等等。这些实现逻辑散布于整个PetShop系统中，在我看来，是可以在此基础上进行重构的。也就是说，我们可以为整个系统提供类似于“ServiceLocator”的实现：publicstaticclassServiceLocator{privatestaticreadonlystringdalPath=ConfigurationManager.AppSettings["WebDAL"];privatestaticreadonlystringorderPath=ConfigurationManager.AppSettings["OrdersDAL"];//……privatestaticreadonlystringorderStategyPath=ConfigurationManager.AppSettings["OrderStrategyAssembly"];
publicstaticobjectLocateDALObject(stringclassName){stringfullPath=dalPath+"."+className;returnAssembly.Load(dalPath).CreateInstance(fullPath);}publicstaticobjectLocateDALOrderObject(stringclassName){stringfullPath=orderPath+"."+className;returnAssembly.Load(orderPath).CreateInstance(fullPath);}publicstaticobjectLocateOrderStrategyObject(stringclassName){stringfullPath=orderStategyPath+"."+className;returnAssembly.Load(orderStategyPath).CreateInstance(fullPath);}//……}
publicOrderInfoReceive(inttimeout){base.timeout=TimeSpan.FromSeconds(Convert.ToDouble(timeout));returnReceive();}
Orderorder=newOrder();while(true){//queuetimeoutvariablesTimeSpandatetimeStarting=newTimeSpan(DateTime.Now.Ticks);doubleelapsedTime=0;
intprocessedItems=0;
ArrayListqueueOrders=newArrayList();
using(TransactionScopets=newTransactionScope(TransactionScopeOption.Required,tsTimeout)){//Receivetheordersfromthequeuefor(intj=0;j //updateelapsedtimeelapsedTime=newTimeSpan(DateTime.Now.Ticks).TotalSeconds-datetimeStarting.TotalSeconds;}catch(TimeoutException){//exitloopbecausenomoremessagesarewaitingj=batchSize;}}//processthequeuedordersfor(intk=0;k //batchcompleteorMSMQreceivetimedoutts.Complete();} Console.WriteLine("(ThreadId"+Thread.CurrentThread.ManagedThreadId+")batchfinished,"+processedItems+"items,in"+elapsedTime.ToString()+"seconds.");}}首先，它会通过PetShop.BLL.Order类的公共方法ReceiveFromQueue()来获取消息队列中的订单数据，并将其放入到一个ArrayList对象中，然而再调用PetShop.BLL.Order类的Insert方法将其插入到Order和Inventory数据库中。在PetShop.BLL.Order类中，并不是直接执行插入订单的操作，而是调用了IOrderStrategy接口的Insert()方法：publicvoidInsert(OrderInfoorder){//CallcreditcardprocesorProcessCreditCard(order); 四、PetShop之ASP.NET缓存 如果对微型计算机硬件系统有足够的了解，那么我们对于Cache这个名词一定是耳熟能详的。在CPU以及主板的芯片中，都引入了这种名为高速缓冲存储器（Cache）的技术。因为Cache的存取速度比内存快，因而引入Cache能够有效的解决CPU与内存之间的速度不匹配问题。硬件系统可以利用Cache存储CPU访问概率高的那些数据，当CPU需要访问这些数据时，可以直接从Cache中读取，而不必访问存取速度相对较慢的内存，从而提高了CPU的工作效率。软件设计借鉴了硬件设计中引入缓存的机制以改善整个系统的性能，尤其是对于一个数据库驱动的Web应用程序而言，缓存的利用是不可或缺的，毕竟，数据库查询可能是整个Web站点中调用最频繁但同时又是执行最缓慢的操作之一，我们不能被它老迈的双腿拖缓我们前进的征程。缓存机制正是解决这一缺陷的加速器。 4.1ASP.NET缓存概述 作为.Net框架下开发Web应用程序的主打产品，ASP.NET充分考虑了缓存机制。通过某种方法，将系统需要的数据对象、Web页面存储在内存中，使得Web站点在需要获取这些数据时，不需要经过繁琐的数据库连接、查询和复杂的逻辑运算，就可以“触手可及”，如“探囊取物”般容易而快速，从而提高整个Web系统的性能。 ASP.NET提供了两种基本的缓存机制来提供缓存功能。一种是应用程序缓存，它允许开发者将程序生成的数据或报表业务对象放入缓存中。另外一种缓存机制是页输出缓存，利用它，可以直接获取存放在缓存中的页面，而不需要经过繁杂的对该页面的再次处理。 应用程序缓存其实现原理说来平淡无奇，仅仅是通过ASP.NET管理内存中的缓存空间。放入缓存中的应用程序数据对象，以键/值对的方式存储，这便于用户在访问缓存中的数据项时，可以根据key值判断该项是否存在缓存中。 放入在缓存中的数据对象其生命周期是受到限制的，即使在整个应用程序的生命周期里，也不能保证该数据对象一直有效。ASP.NET可以对应用程序缓存进行管理，例如当数据项无效、过期或内存不足时移除它们。此外，调用者还可以通过CacheItemRemovedCallback委托，定义回调方法使得数据项被移除时能够通知用户。 在.NetFramework中，应用程序缓存通过System.Web.Caching.Cache类实现。它是一个密封类，不能被继承。对于每一个应用程序域，都要创建一个Cache类的实例，其生命周期与应用程序域的生命周期保持一致。我们可以利用Add或Insert方法，将数据项添加到应用程序缓存中，如下所示：Cache["First"]="FirstItem";Cache.Insert("Second","SecondItem"); 我们还可以为应用程序缓存添加依赖项，使得依赖项发生更改时，该数据项能够从缓存中移除：string[]dependencies={"Second"};Cache.Insert("Third","ThirdItem",newSystem.Web.Caching.CacheDependency(null,dependencies)); 只要没有超过Duration设置的期限值，当用户访问相同的页面或控件时，就可以直接在缓存中获取。使用VaryByParam参数可以根据设置的参数值建立不同的缓存。例如在一个输出天气预报结果的页面中，如果需要为一个ID为txtCity的TextBox控件建立缓存，其值将显示某城市的气温，那么我们可以进行如下的设置：<%@OutputCacheDuration=”60”VaryByParam=”txtCity”%> 如此一来，ASP.NET会对txtCity控件的值进行判断，只有输入的值与缓存值相同，才从缓存中取出相应的值。这就有效地避免了因为值的不同而导致输出错误的数据。 利用缓存的机制对性能的提升非常明显。通过ACT（ApplicationCenterTest）的测试，可以发现设置缓存后执行的性能比未设置缓存时的性能足足提高三倍多。 引入缓存看来是提高性能的“完美”解决方案，然而“金无足赤，人无完人”，缓存机制也有缺点，那就是数据过期的问题。一旦应用程序数据或者页面结果值发生的改变，那么在缓存有效期范围内，你所获得的结果将是过期的、不准确的数据。我们可以想一想股票系统利用缓存所带来的灾难，当你利用错误过期的数据去分析股市的风云变幻时，你会发现获得的结果真可以说是“失之毫厘，谬以千里”，看似大好的局面就会像美丽的泡沫一样，用针一戳，转眼就消失得无影无踪。 那么我们是否应该为了追求高性能，而不顾所谓“数据过期”所带来的隐患呢？显然，在类似于股票系统这种数据更新频繁的特定场景下，数据过期的糟糕表现甚至比低效的性能更让人难以接受。故而，我们需要在性能与数据正确性间作出权衡。所幸的是，.NetFramework2.0引入了一种新的缓存机制，它为我们的“鱼与熊掌兼得”带来了技术上的可行性。 .Net2.0引入的自定义缓存依赖项，特别是基于MS-SQLServer的SqlCacheDependency特性，使得我们可以避免“数据过期”的问题，它能够根据数据库中相应数据的变化，通知缓存，并移除那些过期的数据。事实上，在PetShop4.0中，就充分地利用了SqlCacheDependency特性。 4.2SqlCacheDependency特性 4.2.1利用aspnet_regsql工具 aspnet_regsql工具位于Windows/Microsoft.NET/Framework/[版本]文件夹中。如果直接双击该工具的执行文件，会弹出一个向导对话框，提示我们完成相应的操作： 如图4-1所示中的提示信息，说明该向导主要用于配置SQLServer数据库，如membership，profiles等信息，如果要配置SqlCacheDependency，则需要以命令行的方式执行。以PetShop4.0为例，数据库名为MSPetShop4，则命令为：aspnet_regsql-Slocalhost-E-dMSPetShop4-ed 以下是该工具的命令参数说明：-显示该工具的帮助功能；-S后接的参数为数据库服务器的名称或者IP地址；-U后接的参数为数据库的登陆用户名；-P后接的参数为数据库的登陆密码；-E当使用windows集成验证时，使用该功能；-d后接参数为对哪一个数据库采用SqlCacheDependency功能；-t后接参数为对哪一个表采用SqlCacheDependency功能；-ed允许对数据库使用SqlCacheDependency功能；-dd禁止对数据库采用SqlCacheDependency功能；-et允许对数据表采用SqlCacheDependency功能；-dt禁止对数据表采用SqlCacheDependency功能；-lt列出当前数据库中有哪些表已经采用sqlcachedependency功能。 其中，AspNet_SqlCacheUpdateChangeIdStoredProcedure即是工具添加的一组存储过程中的一个。当对Product数据表执行Insert、Update或Delete等操作时，就会激活触发器，然后执行AspNet_SqlCacheUpdateChangeIdStoredProcedure存储过程。其执行的过程就是修改AspNet_SqlCacheTablesForChangeNotification数据表的changeId字段值：CREATEPROCEDUREdbo.AspNet_SqlCacheUpdateChangeIdStoredProcedure@tableNameNVARCHAR(450)ASBEGINUPDATEdbo.AspNet_SqlCacheTablesForChangeNotificationWITH(ROWLOCK)SETchangeId=changeId+1WHEREtableName=@tableNameENDGO 4.2.2利用SqlCacheDependencyAdmin类 我们也可以利用编程的方式来来管理数据库对SqlCacheDependency特性的使用。该类包含了五个重要的方法： 表4-1SqlCacheDependencyAdmin类的主要方法 假设我们定义了如下的数据库连接字符串：conststringconnectionStr="Server=localhost;Database=MSPetShop4"; 那么为数据库MSPetShop4启用SqlCacheDependency对象更改通知的实现为：protectedvoidPage_Load(objectsender,EventArgse){if(!IsPostBack){SqlCacheDependencyAdmin.EnableNotifications(connectionStr);}} 为数据表Product启用SqlCacheDependency对象更改通知的实现则为：SqlCacheDependencyAdmin.EnableTableForNotifications(connectionStr,"Product"); 虽然说编程方式赋予了程序员更大的灵活性，但aspnet_regsql工具却提供了更简单的方法实现对SqlCacheDependency的配置与管理。PetShop4.0采用的正是aspnet_regsql工具的办法，它编写了一个文件名为InstallDatabases.cmd的批处理文件，其中包含了对aspnet_regsql工具的执行，并通过安装程序去调用该文件，实现对SQLServer的配置。 4.3在PetShop4.0中ASP.NET缓存的实现 PetShop作为一个B2C的宠物网上商店，需要充分考虑访客的用户体验，如果因为数据量大而导致Web服务器的响应不及时，页面和查询数据迟迟得不到结果，会因此而破坏客户访问网站的心情，在耗尽耐心的等待后，可能会失去这一部分客户。无疑，这是非常糟糕的结果。因而在对其进行体系架构设计时，整个系统的性能就显得殊为重要。然而，我们不能因噎废食，因为专注于性能而忽略数据的正确性。在PetShop3.0版本以及之前的版本，因为ASP.NET缓存的局限性，这一问题并没有得到很好的解决。PetShop4.0则引入了SqlCacheDependency特性，使得系统对缓存的处理较之以前大为改观。 4.3.1CacheDependency接口 在PetShop4.0的命名空间PetShop.ICacheDependency中，定义了名为IPetShopCacheDependency接口，它仅包含了一个接口方法：publicinterfaceIPetShopCacheDependency{AggregateCacheDependencyGetDependency();} AggregateCacheDependency是.NetFramework2.0新增的一个类，它负责监视依赖项对象的集合。当这个集合中的任意一个依赖项对象发生改变时，该依赖项对象对应的缓存对象都将被自动移除。AggregateCacheDependency类起到了组合CacheDependency对象的作用，它可以将多个CacheDependency对象甚至于不同类型的CacheDependency对象与缓存项建立关联。由于PetShop需要为Category、Product和Item数据表建立依赖项，因而IPetShopCacheDependency的接口方法GetDependency()其目的就是返回建立了这些依赖项的AggregateCacheDependency对象。 4.3.2CacheDependency实现 CacheDependency的实现正是为Category、Product和Item数据表建立了对应的SqlCacheDependency类型的依赖项，如代码所示：publicabstractclassTableDependency:IPetShopCacheDependency{//Thisistheseparatorthat'susedinweb.configprotectedchar[]configurationSeparator=newchar[]{','}; protectedAggregateCacheDependencydependency=newAggregateCacheDependency();protectedTableDependency(stringconfigKey){stringdbName=ConfigurationManager.AppSettings["CacheDatabaseName"];stringtableConfig=ConfigurationManager.AppSettings[configKey];string[]tables=tableConfig.Split(configurationSeparator); foreach(stringtableNameintables)dependency.Add(newSqlCacheDependency(dbName,tableName));}publicAggregateCacheDependencyGetDependency(){returndependency;}} 需要建立依赖项的数据库与数据表都配置在web.config文件中，其设置如下： 根据各个数据表间的依赖关系，因而不同的数据表需要建立的依赖项也是不相同的，从配置文件中的value值可以看出。然而不管建立依赖项的多寡，其创建的行为逻辑都是相似的，因而在设计时，抽象了一个共同的类TableDependency，并通过建立带参数的构造函数，完成对依赖项的建立。由于接口方法GetDependency()的实现中，返回的对象dependency是在受保护的构造函数创建的，因此这里的实现方式也可以看作是TemplateMethod模式的灵活运用。例如TableDependency的子类Product，就是利用父类的构造函数建立了Product、Category数据表的SqlCacheDependency依赖：publicclassProduct:TableDependency{publicProduct():base("ProductTableDependency"){}} 如果需要自定义CacheDependency，那么创建依赖项的方式又有不同。然而不管是创建SqlCacheDependency对象，还是自定义的CacheDependency对象，都是将这些依赖项添加到AggregateCacheDependency类中，因而我们也可以为自定义CacheDependency建立专门的类，只要实现IPetShopCacheDependency接口即可。 4.3.3CacheDependency工厂 继承了抽象类TableDependency的Product、Category和Item类均需要在调用时创建各自的对象。由于它们的父类TableDependency实现了接口IPetShopCacheDependency，因而它们也间接实现了IPetShopCacheDependency接口，这为实现工厂模式提供了前提。 在PetShop4.0中，依然利用了配置文件和反射技术来实现工厂模式。命名空间PetShop.CacheDependencyFactory中，类DependencyAccess即为创建IPetShopCacheDependency对象的工厂类：publicstaticclassDependencyAccess{publicstaticIPetShopCacheDependencyCreateCategoryDependency(){returnLoadInstance("Category");}publicstaticIPetShopCacheDependencyCreateProductDependency(){returnLoadInstance("Product");}publicstaticIPetShopCacheDependencyCreateItemDependency(){returnLoadInstance("Item");}privatestaticIPetShopCacheDependencyLoadInstance(stringclassName){stringpath=ConfigurationManager.AppSettings["CacheDependencyAssembly"];stringfullyQualifiedClass=path+"."+className;return(IPetShopCacheDependency)Assembly.Load(path).CreateInstance(fullyQualifiedClass);}}整个工厂模式的实现如图4-3所示： 虽然DependencyAccess类创建了实现了IPetShopCacheDependency接口的类Category、Product、Item，然而我们之所以引入IPetShopCacheDependency接口，其目的就在于获得创建了依赖项的AggregateCacheDependency类型的对象。我们可以调用对象的接口方法GetDependency()，如下所示：AggregateCacheDependencydependency=DependencyAccess.CreateCategoryDependency().GetDependency(); 为了方便调用者，似乎我们可以对DependencyAccess类进行改进，将原有的CreateCategoryDependency()方法，修改为创建AggregateCacheDependency类型对象的方法。 然而这样的做法扰乱了作为工厂类的DependencyAccess的本身职责，且创建IPetShopCacheDependency接口对象的行为仍然有可能被调用者调用，所以保留原有的DependencyAccess类仍然是有必要的。 在PetShop4.0的设计中，是通过引入Facade模式以方便调用者更加简单地获得AggregateCacheDependency类型对象。 4.3.4引入Facade模式 利用Facade模式可以将一些复杂的逻辑进行包装，以方便调用者对这些复杂逻辑的调用。就好像提供一个统一的门面一般，将内部的子系统封装起来，统一为一个高层次的接口。一个典型的Facade模式示意图如下所示： Facade模式的目的并非要引入一个新的功能，而是在现有功能的基础上提供一个更高层次的抽象，使得调用者可以直接调用，而不用关心内部的实现方式。以CacheDependency工厂为例，我们需要为调用者提供获得AggregateCacheDependency对象的简便方法，因而创建了DependencyFacade类：publicstaticclassDependencyFacade{privatestaticreadonlystringpath=ConfigurationManager.AppSettings["CacheDependencyAssembly"];publicstaticAggregateCacheDependencyGetCategoryDependency(){if(!string.IsNullOrEmpty(path))returnDependencyAccess.CreateCategoryDependency().GetDependency();elsereturnnull;}publicstaticAggregateCacheDependencyGetProductDependency(){if(!string.IsNullOrEmpty(path))returnDependencyAccess.CreateProductDependency().GetDependency();elsereturnnull;}publicstaticAggregateCacheDependencyGetItemDependency(){if(!string.IsNullOrEmpty(path))returnDependencyAccess.CreateItemDependency().GetDependency();elsereturnnull;}} 比起直接调用DependencyAccess类的GetDependency()方法而言，除了方法更简单之外，同时它还对CacheDependencyAssembly配置节进行了判断，如果其值为空，则返回null对象。 在PetShop.Web的App_Code文件夹下，静态类WebUtility的GetCategoryName()和GetProductName()方法调用了DependencyFacade类。例如GetCategoryName()方法：publicstaticstringGetCategoryName(stringcategoryId){Categorycategory=newCategory();if(!enableCaching)returncategory.GetCategory(categoryId).Name; stringcacheKey=string.Format(CATEGORY_NAME_KEY,categoryId); //检查缓存中是否存在该数据项;stringdata=(string)HttpRuntime.Cache[cacheKey];if(data==null){//通过web.config的配置获取duration值;intcacheDuration=int.Parse(ConfigurationManager.AppSettings["CategoryCacheDuration"]);//如果缓存中不存在该数据项，则通过业务逻辑层访问数据库获取;data=category.GetCategory(categoryId).Name;//通过Facade类创建AggregateCacheDependency对象;AggregateCacheDependencycd=DependencyFacade.GetCategoryDependency();//将数据项以及AggregateCacheDependency对象存储到缓存中;HttpRuntime.Cache.Add(cacheKey,data,cd,DateTime.Now.AddHours(cacheDuration),Cache.NoSlidingExpiration,CacheItemPriority.High,null);}returndata;} GetCategoryName()方法首先会检查缓存中是否已经存在CategoryName数据项，如果已经存在，就通过缓存直接获取数据；否则将通过业务逻辑层调用数据访问层访问数据库获得CategoryName，在获得了CategoryName后，会将新获取的数据连同DependencyFacade类创建的AggregateCacheDependency对象添加到缓存中。 WebUtility静态类被表示层的许多页面所调用，例如Product页面：publicpartialclassProducts:System.Web.UI.Page{protectedvoidPage_Load(objectsender,EventArgse){Page.Title=WebUtility.GetCategoryName(Request.QueryString["categoryId"]);}} 显示页面title的逻辑是放在Page_Load事件方法中，因而每次打开该页面都要执行获取CategoryName的方法。如果没有采用缓存机制，当Category数据较多时，页面的显示就会非常缓慢。 4.3.5引入Proxy模式 以PetShop.BLL.Product业务对象为例，PetShop为其建立了代理对象ProductDataProxy，并在GetProductByCategory()等方法中，引入了缓存机制，例如：publicstaticclassProductDataProxy{ privatestaticreadonlyintproductTimeout=int.Parse(ConfigurationManager.AppSettings["ProductCacheDuration"]);privatestaticreadonlyboolenableCaching=bool.Parse(ConfigurationManager.AppSettings["EnableCaching"]);publicstaticIListGetProductsByCategory(stringcategory){Productproduct=newProduct(); if(!enableCaching)returnproduct.GetProductsByCategory(category); stringkey="product_by_category_"+category;IListdata=(IList)HttpRuntime.Cache[key]; //Checkifthedataexistsinthedatacacheif(data==null){data=product.GetProductsByCategory(category); //CreateaAggregateCacheDependencyobjectfromthefactoryAggregateCacheDependencycd=DependencyFacade.GetProductDependency(); //Storetheoutputinthedatacache,andAddthenecessaryAggregateCacheDependencyobjectHttpRuntime.Cache.Add(key,data,cd,DateTime.Now.AddHours(productTimeout),Cache.NoSlidingExpiration,CacheItemPriority.High,null);}returndata;}} 引入Proxy模式，实现了在缓存级别上对业务对象的封装，增强了对业务对象的控制。由于暴露在对象外的方法是一致的，因而对于调用方而言，调用代理对象与真实对象并没有实质的区别。 从职责分离与分层设计的角度分析，我更希望这些Proxy对象是被定义在业务逻辑层中，而不像在PetShop的设计那样，被划分到表示层UI中。此外，如果需要考虑程序的可扩展性与可替换性，我们还可以为真实对象与代理对象建立统一的接口或抽象类。然而，单以PetShop的表示层调用来看，采用静态类与静态方法的方式，或许更为合理。我们需要谨记，“过度设计”是软件设计的警戒线。 如果需要对UI层采用缓存机制，将应用程序数据存放到缓存中，就可以调用这些代理对象。以ProductsControl用户控件为例，调用方式如下：productsList.DataSource=ProductDataProxy.GetProductsByCategory(categoryKey); productsList对象属于自定义的CustomList类型，这是一个派生自System.Web.UI.WebControls.DataList控件的类，它的DataSource属性可以接受IList集合对象。不过在PetShop4.0的设计中，对于类似于ProductsControl类型的控件而言，采用的缓存机制是页输出缓存。我们可以从ProductsControl.ascx页面的Source代码中发现端倪：<%@OutputCacheDuration="100000"VaryByParam="page;categoryId"%> 采用页输出缓存，并且利用ControlCachePolicy设置输出缓存，能够将业务数据与整个页面放入到缓存中。这种方式比起应用程序缓存而言，在性能上有很大的提高。同时，它又通过引入的SqlCacheDependency特性有效地避免了“数据过期”的缺点，因而在PetShop4.0中被广泛采用。相反，之前为Product、Category、Item业务对象建立的代理对象则被“投闲散置”，仅仅作为一种设计方法的展示而“幸存”与整个系统的源代码中。 业务逻辑层在体系架构中的位置很关键，它处于数据访问层与表示层中间，起到了数据交换中承上启下的作用。由于层是一种弱耦合结构，层与层之间的依赖是向下的，底层对于上层而言是“无知”的，改变上层的设计对于其调用的底层而言没有任何影响。如果在分层设计时，遵循了面向接口设计的思想，那么这种向下的依赖也应该是一种弱依赖关系。因而在不改变接口定义的前提下，理想的分层式架构，应该是一个支持可抽取、可替换的“抽屉”式架构。正因为如此，业务逻辑层的设计对于一个支持可扩展的架构尤为关键，因为它扮演了两个不同的角色。对于数据访问层而言，它是调用者；对于表示层而言，它却是被调用者。依赖与被依赖的关系都纠结在业务逻辑层上，如何实现依赖关系的解耦，则是除了实现业务逻辑之外留给设计师的任务。 5.1与领域专家合作设计业务逻辑层最大的障碍不在于技术，而在于对领域业务的分析与理解。很难想象一个不熟悉该领域业务规则和流程的架构设计师能够设计出合乎客户需求的系统架构。几乎可以下定结论的是，业务逻辑层的设计过程必须有领域专家的参与。在我曾经参与开发的项目中，所涉及的领域就涵盖了电力、半导体、汽车等诸多行业，如果缺乏这些领域的专家，软件架构的设计尤其是业务逻辑层的设计就无从谈起。这个结论唯一的例外是，架构设计师同时又是该领域的专家。然而，正所谓“千军易得，一将难求”，我们很难寻觅到这样卓越出众的人才。 领域专家在团队中扮演的角色通常称为BusinessConsultor（业务咨询师），负责提供与领域业务有关的咨询，与架构师一起参与架构与数据库的设计，撰写需求文档和设计用例（或者用户故事UserStory）。如果在测试阶段，还应该包括撰写测试用例。理想的状态是，领域专家应该参与到整个项目的开发过程中，而不仅仅是需求阶段。 传统的软件开发模型同样重视与领域专家的合作，但这种合作主要集中在需求分析阶段。例如瀑布模型，就非常强调早期计划与需求调研。然而这种未雨绸缪的早期计划方式，对架构师与需求调研人员的技能要求非常高，它强调需求文档的精确性，一旦分析出现偏差，或者需求发生变更，当项目开发进入设计阶段后，由于缺乏与领域专家沟通与合作的机制，开发人员估量不到这些错误与误差，因而难以及时作出修正。一旦这些问题像毒瘤一般在系统中蔓延开来，逐渐暴露在开发人员面前时，已经成了一座难以逾越的高山。我们需要消耗更多的人力物力，才能够修正这些错误，从而导致开发成本成数量级的增加，甚至于导致项目延期。当然还有一个好的选择，就是放弃整个项目。这样的例子不胜枚举，事实上，项目开发的“滑铁卢”，究其原因，大部分都是因为业务逻辑分析上出现了问题。 迭代式模型较之瀑布模型有很大地改进，因为它允许变更、优化系统需求，整个迭代过程实际上就是与领域专家的合作过程，通过向客户演示迭代所产生的系统功能，从而及时获取反馈，并逐一解决迭代演示中出现的问题，保证系统向着合乎客户需求的方向演化。因而，迭代式模型往往能够解决早期计划不足的问题，它允许在发现缺陷的时候，在需求变更的时候重新设计、重新编码并重新测试。 无论采用何种开发模型，与领域专家的合作都将成为项目成败与否的关键。这基于一个软件开发的普遍真理，那就是世界上没有不变的需求。一句经典名言是：“没有不变的需求，世上的软件都改动过3次以上，唯一一个只改动过两次的软件的拥有者已经死了，死在去修改需求的路上。”一语道尽了软件开发的残酷与艰辛！ 那么应该如何加强与领域专家的合作呢？JamesCarey和BrentCarlson根据他们在参与的IBMSanFrancisco项目中获得的经验，提出了InnocentQuestions模式，其意义即“改进领域专家和技术专家的沟通质量”。在一个项目团队中，如果我们没有一位既能担任首席架构师，同时又是领域专家的人选，那么加强领域专家与技术专家的合作就显得尤为重要了。毕竟，作为一个领域专家而言，可能并不熟悉软件设计方法学，也不具备面向对象开发和架构设计的能力，同样，大部分技术专家很有可能对该项目所涉及的业务领域仅停留在一知半解的地步。如果领域专家与技术专家不能有效沟通，则整个项目的前途就岌岌可危了。 InnocentQuestions模式提出的解决方案包括：（1）选用可以与人和谐相处的人员组建开发团队；（2）清楚地定义角色和职权；（3）明确定义需要的交互点；（4）保持团队紧密；（5）雇佣优秀的人。 事实上，这已经从技术的角度上升到对团队的管理层次了。就好比篮球运动一样，即使你的球队集合了五名世界上最顶尖最有天赋的球员，如果各自为战，要想取得比赛的胜利依旧是非常困难的。团队精神与权责分明才是取得胜利的保障，软件开发同样如此。 与领域专家合作的基础是保证开发团队中永远保留至少一名领域专家。他可以是系统的客户，第三方公司的咨询师，最理想是自己公司雇佣的专家。如果项目中缺乏这样的一个人，那么我的建议是去雇佣他，如果你不想看到项目遭遇“西伯利亚寒流”的话。 确定领域专家的角色任务与职责。必须要让团队中的每一个人明确领域专家在整个团队中究竟扮演什么样的角色，他的职责是什么。一个合格的领域专家必须对业务领域有足够深入的理解，他应该是一个能够俯瞰整个系统需求、总揽全局的人物。在项目开发过程中，将由他负责业务规则和流程的制定，负责与客户的沟通，需求的调研与讨论，并于设计师一起参与系统架构的设计。编档是领域专家必须参与的工作，无论是需求文档还是设计文档，以及用例的编写，领域专家或者提出意见，或者作为撰写的作者，至少他也应该是评审委员会的重要成员。 加强与客户的沟通。客户同时也可以作为团队的领域专家，极限编程的现场客户原则是最好的示例。但现实并不都如此的完美，在无法要求客户成为开发团队中的固定一员时，聘请或者安排一个专门的领域专家，加强与客户的沟通，就显得尤为重要。项目可以通过领域专家获得客户的及时反馈。而通过领域专家去了解变更了的需求，会在最大程度上减少需求误差的可能。 5.2业务逻辑层的模式应用MartinFowler在《企业应用架构模式》一书中对领域层（即业务逻辑层）的架构模式作了整体概括，他将业务逻辑设计分为三种主要的模式：TransactionScript、DomainModel和TableModule。 TransactionScript模式将业务逻辑看作是一个个过程，是比较典型的面向过程开发模式。应用TransactionScript模式可以不需要数据访问层，而是利用SQL语句直接访问数据库。为了有效地管理SQL语句，可以将与数据库访问有关的行为放到一个专门的Gateway类中。应用TransactionScript模式不需要太多面向对象知识，简单直接的特性是该模式全部价值之所在。因而，在许多业务逻辑相对简单的项目中，应用TransactionScript模式较多。 DomainModel模式是典型的面向对象设计思想的体现。它充分考虑了业务逻辑的复杂多变，引入了Strategy模式等设计模式思想，并通过建立领域对象以及抽象接口，实现模式的可扩展性，并利用面向对象思想与身俱来的特性，如继承、封装与多态，用于处理复杂多变的业务逻辑。唯一制约该模式应用的是对象与关系数据库的映射。我们可以引入ORM工具，或者利用DataMapper模式来完成关系向对象的映射。 与DomainModel模式相似的是TableModule模式，它同样具有面向对象设计的思想，唯一不同的是它获得的对象并非是单纯的领域对象，而是DataSet对象。如果为关系数据表与对象建立一个简单的映射关系，那么DomainModel模式就是为数据表中的每一条记录建立一个领域对象，而TableModule模式则是将整个数据表看作是一个完整的对象。虽然利用DataSet对象会丢失面向对象的基本特性，但它在为表示层提供数据源支持方面却有着得天独厚的优势。尤其是在.Net平台下，ADO.NET与Web控件都为TableModule模式提供了生长的肥沃土壤。 5.3PetShop的业务逻辑层设计PetShop在业务逻辑层设计中引入了DomainModel模式，这与数据访问层对于数据对象的支持是分不开的。由于PetShop并没有对宠物网上商店的业务逻辑进行深入，也省略了许多复杂细节的商务逻辑，因而在DomainModel模式的应用上并不明显。最典型地应该是对Order领域对象的处理方式，通过引入Strategy模式完成对插入订单行为的封装。关于这一点，我已在第27章有了详尽的描述，这里就不再赘述。 Cart类通过一个Dictionary对象来负责对购物车内容的存储，同时定义了Add、Remove、Clear等方法，来实现对购物车内容的管理。 在前面我提到PetShop业务逻辑层中的领域对象仅仅是完成对数据对象的简单封装，但这种分离层次的方法在架构设计中依然扮演了举足轻重的作用。以Cart类的Add()方法为例，在方法内部引入了PetShop.BLL.Item领域对象，并调用了Item对象的GetItem()方法。如果没有在业务逻辑层封装Item对象，而是直接调用数据访问层的Item数据对象，为保证层次间的弱依赖关系，就需要调用工厂对象的工厂方法来创建PetShop.IDAL.IItem接口类型对象。一旦数据访问层的Item对象被多次调用，就会造成重复代码，既不离于程序的修改与扩展，也导致程序结构生长为臃肿的态势。 此外，领域对象对数据访问层数据对象的封装，也有利于表示层对业务逻辑层的调用。在三层式架构中，表示层应该是对于数据访问层是“无知”的，这样既减少了层与层间的依赖关系，也能有效避免“循环依赖”的后果。 如此一来，我们可以为Cart类定义一个有参数的构造函数：privateIOnSaleStrategym_onSale;publicCart(IOnSaleStrategyonSale){m_onSale=onSale;} 那么Total属性就可以修改为：publicdecimalTotal{get{returnm_onSale.CalculateTotalPrice(cartItems);}} 如此一来，就可以使得Cart类能够有效地支持网站推出的促销计划，也符合开-闭原则。同样的，这种设计方式也是DomainModel模式的体现。修改后的设计如图5-1所示： 图5-1引入Strategy模式 作为一个B2C的电子商务架构，它所涉及的业务领域已为大部分设计师与开发人员所熟悉，因而在本例中，与领域专家的合作显得并不那么重要。然而，如果我们要开发一个成功的电子商务网站，与领域专家的合作仍然是必不可少的。以订单的管理而言，如果考虑复杂的商业应用，就需要管理订单的跟踪（Tracking），与网上银行的合作，账户安全性，库存管理，物流管理，以及客户关系管理（CRM）。整个业务过程却涵盖了诸如电子商务、银行、物流、客户关系学等诸多领域，如果没有领域专家的参与，业务逻辑层的设计也许会“败走麦城”。 5.4与数据访问层的通信业务逻辑层需要与数据访问层通信，利用数据访问层访问数据库，因此业务逻辑层与数据访问层之间就存在依赖关系。在数据访问层引入接口程序集以及数据工厂的设计前提下，能够做到两者间关系为弱依赖。我们从业务逻辑层的引用程序集中可以看到，BLL模块并没有引用SQLServerDAL和OracleDAL程序集。在业务逻辑层中，有关数据访问层中数据对象的调用，均利用多态原理定义了抽象的接口类型对象，然后利用工厂对象的工厂方法创建具体的数据对象。如PetShop.BLL.PetShop领域对象所示：namespacePetShop.BLL{publicclassProduct{//根据工厂对象创建IProduct接口类型实例;privatestaticreadonlyIProductdal=PetShop.DALFactory.DataAccess.CreateProduct();//调用IProduct对象的接口方法GetProductByCategory();publicIListGetProductsByCategory(stringcategory){//如果为空则新建List对象;if(string.IsNullOrEmpty(category))returnnewList(); //通过数据访问层的数据对象访问数据库;returndal.GetProductsByCategory(category);}//其他方法略;}} 在领域对象Product类中，利用数据访问层的工厂类DALFactory.DataAccess创建PetShop.IDAL.IProduct类型的实例，如此就可以解除对具体程序集SQLServerDAL或OracleDAL的依赖。只要PetShop.IDAL的接口方法不变，即使修改了IDAL接口模块的具体实现，都不会影响业务逻辑层的实现。这种松散的弱耦合关系，才能够最大程度地支持架构的可扩展。 5.5面向接口设计也许是业务逻辑比较简单地缘故，在业务逻辑层的设计中，并没有秉承在数据访问层中面向接口设计的思想。除了完成对插入订单策略的抽象外，整个业务逻辑层仅以BLL模块实现，没有为领域对象定义抽象的接口。因而PetShop的表示层与业务逻辑层就存在强依赖关系，如果业务逻辑层中的需求发生变更，就必然会影响表示层的实现。唯一可堪欣慰的是，由于我们采用分层式架构将用户界面与业务领域逻辑完全分离，一旦用户界面发生更改，例如将B/S架构修改为C/S架构，那么业务逻辑层的实现模块是可以完全重用的。 然而，最理想的方式仍然是面向接口设计。根据第28章对ASP.NET缓存的分析，我们可以将表示层App_Code下的Proxy类与Utility类划分到业务逻辑层中，并修改这些静态类为实例类，并将这些类中与业务领域有关的方法抽象为接口，然后建立如数据访问层一样的抽象工厂。通过“依赖注入”方式，解除与具体领域对象类的依赖，使得表示层仅依赖于业务逻辑层的接口程序集以及工厂模块。 那么，这样的设计是否有“过度设计”的嫌疑呢？我们需要依据业务逻辑的需求情况而定。此外，如果我们需要引入缓存机制，为领域对象创建代理类，那么为领域对象建立接口，就显得尤为必要。我们可以建立一个专门的接口模块IBLL，用以定义领域对象的接口。以Product领域对象为例，我们可以建立IProduct接口：publicinterfaceIProduct{IListGetProductByCategory(stringcategory);IListGetProductByCategory(string[]keywords);ProductInfoGetProduct(stringproductId);} 在BLL模块中可以引入对IBLL程序集的依赖，则领域对象Product的定义如下：publicclassProduct:IProduct{publicIListGetProductByCategory(stringcategory){//实现略;}publicIListGetProductByCategory(string[]keywords){//实现略;}publicProductInfoGetProduct(stringproductId){//实现略;}} 然后我们可以为代理对象建立专门的程序集BLLProxy，它不仅引入对IBLL程序集的依赖，同时还将依赖于BLL程序集。此时代理对象ProductDataProxy的定义如下：usingPetShop.IBLL;usingPetShop.BLL;namespacePetShop.BLLProxy{publicclassProductDataProxy:IProduct{publicIListGetProductByCategory(stringcategory){Productproduct=newProduct();//其他实现略;}publicIListGetProductByCategory(string[]keywords){//实现略;}publicProductInfoGetProduct(stringproductId){//实现略;}}} 如此的设计正是典型的Proxy模式，其类结构如图5-2所示： 图5-2Proxy模式 图5-3修改后的业务逻辑层与表示层的关系 图5-4则是PetShop4.0原有设计的层次关系图： 图5-4PetShop4.0中表示层与业务逻辑层的关系 通过比较图5-3与图5-4，虽然后者不管是模块的个数，还是模块之间的关系，都相对更加简单，然而WebComponent组件与业务逻辑层之间却是强耦合的，这样的设计不利于应对业务扩展与需求变更。通过引入接口模块IBLL与工厂模块BLLFactory，解除了与具体模块BLL的依赖关系。这种设计对于业务逻辑相对比较复杂的系统而言，更符合面向对象的设计思想，有利于我们建立可抽取、可替换的“抽屉”式三层架构。 六PetShop之表示层设计 表示层（PresentationLayer）的设计可以给系统客户最直接的体验和最十足的信心。正如人与人的相交相识一样，初次见面的感觉总是永难忘怀的。一件交付给客户使用的产品，如果在用户界面（UserInterface，UI）上缺乏吸引人的特色，界面不友好，操作不够体贴，即使这件产品性能非常优异，架构设计合理，业务逻辑都满足了客户的需求，却仍然难以讨得客户的欢心。俗语云：“佛要金装，人要衣装”，特别是对于Web应用程序而言，Web网页就好比人的衣装，代表着整个系统的身份与脸面，是招徕“顾客”的最大卖点。 6.1MVC模式 表示层设计中最重要的模式是MVC（Model-View-Controller，即模型-视图-控制器）模式。MVC模式最早是由SmallTalk语言研究团提出的，被广泛应用在用户交互应用程序中。Controller根据用户请求（Response）修改Model的属性，此时Event（事件）被触发，所有依赖于Model的View对象会自动更新，并基于Model对象产生一个响应（Response）信息，返回给Controller。MartinFowler在《企业应用架构模式》一书中，展示了MVC模式应用的全过程，如图6-1所示： 图6-1典型的MVC模式 如果将MVC模式拆解为三个独立的部分：Model、View、Controller，我们可以通过GOF设计模式来实现和管理它们之间的关系。在体系架构设计中，业务逻辑层的领域对象以及数据访问层的数据值对象都属于MVC模式的Model对象。如果要管理Model与View之间的关系，可以利用Observer模式，View作为观察者，一旦Model的属性值发生变化，就会通知View基于Model的值进行更新。而Controller作为控制用户请求/响应的对象，则可以利用Mediator模式，专门负责请求/响应任务之间的调节。而对于View本身，在面向组件设计思想的基础上，我们通常将它设计为组件或者控件，这些组件或者控件根据自身特性的不同，共同组成一种类似于递归组合的对象结构，因而我们可以利用Composite模式来设计View对象。 然而在.NET平台下，我们并不需要自己去实现MVC模式。对于View对象而言，ASP.NET已经提供了常用的Web控件，我们也可以通过继承System.Web.UI.UserControl，自定义用户控件，并利用ASPX页面组合Web控件来实现视图。ASP.NET定义了System.Web.UI.Page类，它相当于MVC模式的Controller对象，可以处理用户的请求。由于利用了codebehind技术，使得用户界面的显示与UI实现逻辑完全分离，也即是说，View对象与Controller对象成为相对独立的两部分，从而有利于代码的重用性。比较ASP而言，这种编程方式更符合开发人员的编程习惯，同时有利于开发人员与UI设计人员的分工与协作。至于Model对象，则为业务逻辑层的领域对象。此外，.NET平台通过ADO.NET提供了DataSet对象，便于与Web控件的数据源绑定。 6.2PageController模式的应用 通观PetShop的表示层设计，充分利用了ASP.NET的技术特点，通过Web页面与用户控件控制和展现视图，并利用codebehind技术将业务逻辑层的领域对象加入到表示层实现逻辑中，一个典型的PageController模式呼之欲出。 PageController模式是MartinFowler在《企业应用架构模式》中最重要的表示层模式之一。在.NET平台下，PageController模式的实现非常简单，以Products.aspx页面为例。首先在aspx页面中，进行如下的设置： Aspx页面继承自System.Web.UI.Page类。Page类对象通过继承System.Web.UI.Control类，从而拥有了Web控件的特性，同时它还实现了IHttpHandler接口。作为ASP.NET处理HTTPWeb请求的接口，提供了如下的定义： Page类实现了ProcessRequest()方法，通过它可以设置Page对象的Request和Response属性，从而完成对用户请求/相应的控制。然后Page类通过从Control类继承来的Load事件，将View与Model建立关联，如Products.aspx.cs所示： 事件机制恰好是observer模式的实现，当ASPX页面的Load事件被激发后，系统通过WebUtility类（在第28章中有对WebUtility类的详细介绍）的GetCategoryName()方法，获得Category值，并将其显示在页面的Title上。Page对象作为Controller，就好似一个调停者，用于协调View与Model之间的关系。 由于ASPX页面中还可以包含Web控件，这些控件对象同样是作为View对象，通过Page类型对象完成对它们的控制。例如在CheckOut.aspx页面中，当用户发出CheckOut的请求后，作为System.Web.UI.WebControls.Winzard控件类型的wzdCheckOut，会在整个向导过程结束时，触发FinishButtonClick事件，并在该事件中调用领域对象Order的Insert()方法，如下所示： 在上面的一段代码中，非常典型地表达了Model与View之间的关系。它通过获取控件的属性值，作为参数值传递给数据值对象OrderInfo，从而利用页面上产生的订单信息创建订单对象，然后再调用领域对象Order的Inser()方法将OrderInfo对象插入到数据表中。此外，它还对领域对象ShoppingCart的数据项作出判断，如果其值等于0，就在页面中显示UI提示信息。此时，View的内容决定了Model的值，而Model值反过来又决定了View的显示内容。 6.3ASP.NET控件 图6-2ASP.NET控件类的层次结构 ASP.NET控件的执行生命周期如表6-1所示： 阶段 表6-1ASP.NET控件的执行生命周期 在这里，控件设计利用了TemplateMethod模式，Control基类提供了大部分protected虚方法，留待其子类改写其方法。以PetShop4.0为例，就定义了两个ASP.NET控件，它们都属于System.Web.UI.WebControls.WebControl的子类。其中，CustomList控件派生自System.Web.UI.WebControls.DataList，CustomGrid控件则派生自System.Web.UI.WebControls.Repeater。 由于这两个控件都改变了其父类控件的呈现方式，故而，我们可以通过重写父类的Render虚方法，完成控件的自定义。例如CustomGrid控件： 由于CustomGrid继承自Repeater控件，因而它同时还继承了Repeater的DataSource属性，这是一个虚属性，它默认的set访问器属性如下： 对于CustomGrid而言，DataSource属性有着不同的设置行为，因而在定义CustomGrid控件的时候，需要改写DataSource虚属性，如下所示： 当设置的value对象值不为IList类型时，set访问器就将捕获异常，然后将dataSource字段设置为null。 此外，CustomGrid控件类还增加了许多属于自己的属性和方法，例如PageSize、PageCount属性以及SetPage()方法等。正是因为ASP.NET控件引入了Composite模式与TemplateMethod模式，当我们在自定义控件时，就可以通过继承与改写的方式来完成控件的设计。自定义ASP.NET控件一方面可以根据系统的需求实现特定的功能，也能够最大限度地实现对象的重用，既可以减少编码量，同时也有利于未来对程序的扩展与修改。在PetShop4.0中，除了自定义了上述WebControl控件的子控件外，最主要的还是利用了用户控件。在Controls文件夹下，一共定义了11个用户控件，内容涵盖客户地址信息、信用卡信息、购物车信息、期望列表（WishList）信息以及导航信息、搜索结果信息等。它们相当于是一些组合控件，除了包含了子控件的方法和属性外，也定义了一些必要的UI实现逻辑。以ShoppingCartControl用户控件为例，它会在该控件被呈现（Render）之前，做一些数据准备工作，获取购物车数据，并作为数据源绑定到其下的Repeater控件： 在ShoppingCart页面下，我们可以加入该用户控件，如下所示： 6.4ASP.NET2.0新特性 6.4.1Profile特性 Profile提供的功能是针对用户的个性化服务。在ASP.NET1.x版本时，我们可以利用Session、Cookie等方法来存储用户的状态信息。然而Session对象是具有生存期的，一旦生存期结束，该对象保留的值就会失效。Cookie将用户信息保存在客户端，它具有一定的安全隐患，一些重要的信息不能存储在Cookie中。一旦客户端禁止使用Cookie，则该功能就将失去应用的作用。 由于Profile功能需要访问数据库，因而在数据访问层（DAL）定义了和Product等数据表相似的模块结构。首先定义了一个IProfileDAL接口模块，包含了接口IPetShopProfileProvider： 因为PetShop4.0版本分别支持SQLServer和Oracle数据库，因而它分别定义了两个不同的PetShopProfileProvider类，实现IPetShopProfileProvider接口，并放在两个不同的模块SQLProfileDAL和OracleProfileDAL中。具体的实现请参见PetShop4.0的源代码。同样的，PetShop4.0为Profile引入了工厂模式，定义了模块ProfileDALFActory，工厂类DataAccess的定义如下： 定义了PetShop.Profile.PetShopProfileProvider类后，才可以在web.config配置文件中配置如下的配置节： 在配置文件中，针对ShoppingCart、WishList和AccountInfo（它们的类型分别为PetShop.BLL.Cart、PetShop.BLL.Cart、PetShop.Model.AddressInfo）属性分别定义了ShoppingCartProvider、WishListProvider、AccountInfoProvider，它们的类型均为PetShop.Profile.PetShopProfileProvider类型。至于Profile的信息究竟是存储在何种类型的数据库中，则由以下的配置节决定： 而键值为ProfileDAL的值，正是Profile的工厂类PetShop.ProfileDALFactory.DataAccess在利用反射技术创建IPetShopProfileProvider类型对象时获取的。 在表示层中，可以利用页面的Profile属性访问用户的个性化属性，例如在ShoppingCart页面的codebehind代码ShoppingCart.aspx.cs中，调用Profile的ShoppingCart属性： 6.4.2Membership特性 代码中，aspnet_Membership_CreateUser为aspnet_regsql工具为membership创建的存储过程，它的功能就是创建一个用户。 OracleMembershipProvider类中对CreateUser()方法的定义如下： 代码中，InsertUser()方法就是负责用户的创建，而在之前则需要判断创建的用户是否已经存在。InsertUser()方法的定义如下： 对于OracleMembershipProvider而言，配置大致相似： 又例如NewUser.aspx中对CreateUserWizard控件的使用： 6.4.4MasterPage特性 MasterPage相当于是整个Web站点的统一模板，建立的MasterPage文件扩展名为.master。它可以包含静态文本、html元素和服务器控件。MasterPage由特殊的@Master指令识别，如： 使用MasterPage可以为网站建立一个统一的样式，且能够利用它方便地创建一组控件和代码，然后将其应用于一组页。对于那些样式与功能相似的页而言，利用MasterPage就可以集中处理为MasterPage，一旦进行修改，就可以在一个位置上进行更新。 在PetShop4.0中，建立了名为MasterPage.master的MasterPage，它包含了header、LoginView控件、导航菜单以及用于呈现内容的html元素，如图6-3所示： 图6-3PetShop4.0的MasterPage @Master指令的定义如下： MasterPage同样利用codebehind技术，以PetShop4.0的MasterPage为例，codebehind的代码放在文件MasterPage.master.cs中： 注意MasterPage页面不再继承自System.Web.UI.Page，而是继承System.Web.UI.MasterPage类。与Page类继承TemplateControl类不同，它是UserControl类的子类。因此，可以应用在MasterPage上的有效指令与UserControl的可用指令相同，例如AutoEventWireup、ClassName、CodeFile、EnableViewState、WarningLevel等。 MasterPage可以进行嵌套，例如我们建立了父MasterPage页面Parent.master，那么在子MasterPage中，可以利用master属性指定其父MasterPage：<%@MasterLanguage="C#"master="Parent.master"%> 而内容页则可以根据情况指向Parent.master或者Child.master页面。 之所以重写Page_PreInit()方法，是因为MasterPage会在内容页初始化阶段进行合并，也即是说是在PreInit阶段完成MasterPage的分配。ASP.NET2.0引入的新特性，并不仅仅限于上述介绍的内容。例如Theme、Wizard控件等新特性在PetShop4.0中也得到了大量的应用。虽然ASP.NET2.0及时地推陈出新，对表示层的设计有所改善，然而作为ASP.NET2.0的其中一部分，它们仅仅是对现有框架缺失的弥补与改进，属于“锦上添花”的范畴，对于整个表示层设计技术而言，起到的推动作用却非常有限。 直到AJAX（AsynchronousJavaScriptandXML）的出现，整个局面才大为改观。虽然AJAX技术带有几分“旧瓶装新酒”的味道，然而它从诞生之初，就具备了王者气象，大有席卷天下之势。各种支持AJAX技术的框架如雨后春笋般纷纷吐出新芽，支撑起百花齐放的繁荣，气势汹汹地营造出唯AJAX独尊的态势。如今，AJAX已经成为了Web应用的主流开发技术，许多业界大鳄都呲牙咧嘴开始了对这一块新领地的抢滩登陆。例如IBM、Oracle、Yahoo等公司都纷纷启动了开源的AJAX项目。微软也不甘落后，及时地推出了ASP.NETAJAX，这是一个基于ASP.NET的AJAX框架，它包括了ASP.NETAJAX服务端组件和ASP.NETAJAX客户端组件，并集成在VisualStudio中，为ASP.NET开发者提供了一个强大的AJAX应用环境。 我现在还无法预知AJAX技术在未来的走向，然而单单从表示层设计的角度而言，AJAX技术亦然带了一场全新的革命。我们或者可以期待未来的PetShop5.0，可以在表示层设计上带来更多的惊喜。