在进行系统设计时，除了对安全、事务等问题给与足够的重视外，性能也是一个不可避免的问题所在，尤其是一个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集成起来，完成数据的处理。
四 PetShop之ASP.NET缓存
如果对微型计算机硬件系统有足够的了解，那么我们对于Cache这个名词一定是耳熟能详的。在CPU以及主板的芯片中，都引入了这种名为高速缓冲存储器（Cache）的技术。因为Cache的存取速度比内存快，因而引入Cache能够有效的解决CPU与内存之间的速度不匹配问题。硬件系统可以利用Cache存储CPU访问概率高的那些数据，当CPU需要访问这些数据时，可以直接从Cache中读取，而不必访问存取速度相对较慢的内存，从而提高了CPU的工作效率。软件设计借鉴了硬件设计中引入缓存的机制以改善整个系统的性能，尤其是对于一个数据库驱动的Web应用程序而言，缓存的利用是不可或缺的，毕竟，数据库查询可能是整个Web站点中调用最频繁但同时又是执行最缓慢的操作之一，我们不能被它老迈的双腿拖缓我们前进的征程。缓存机制正是解决这一缺陷的加速器。
4.1 ASP.NET缓存概述
作为.Net框架下开发Web应用程序的主打产品，ASP.NET充分考虑了缓存机制。通过某种方法，将系统需要的数据对象、Web页面存储在内存中，使得Web站点在需要获取这些数据时，不需要经过繁琐的数据库连接、查询和复杂的逻辑运算，就可以“触手可及”，如“探囊取物”般容易而快速，从而提高整个Web系统的性能。
ASP.NET提供了两种基本的缓存机制来提供缓存功能。一种是应用程序缓存，它允许开发者将程序生成的数据或报表业务对象放入缓存中。另外一种缓存机制是页输出缓存，利用它，可以直接获取存放在缓存中的页面，而不需要经过繁杂的对该页面的再次处理。
应用程序缓存其实现原理说来平淡无奇，仅仅是通过ASP.NET管理内存中的缓存空间。放入缓存中的应用程序数据对象，以键/值对的方式存储，这便于用户在访问缓存中的数据项时，可以根据key值判断该项是否存在缓存中。
放入在缓存中的数据对象其生命周期是受到限制的，即使在整个应用程序的生命周期里，也不能保证该数据对象一直有效。ASP.NET可以对应用程序缓存进行管理，例如当数据项无效、过期或内存不足时移除它们。此外，调用者还可以通过CacheItemRemovedCallback委托，定义回调方法使得数据项被移除时能够通知用户。
在.Net Framework中，应用程序缓存通过System.Web.Caching.Cache类实现。它是一个密封类，不能被继承。对于每一个应用程序域，都要创建一个Cache类的实例，其生命周期与应用程序域的生命周期保持一致。我们可以利用Add或Insert方法，将数据项添加到应用程序缓存中，如下所示：
Cache["First"] = "First Item";
Cache.Insert("Second", "Second Item");
我们还可以为应用程序缓存添加依赖项，使得依赖项发生更改时，该数据项能够从缓存中移除：
string[] dependencies = {"Second"};
Cache.Insert("Third", "Third Item",
new System.Web.Caching.CacheDependency(null, dependencies));
与之对应的是缓存中数据项的移除。前面提到ASP.NET可以自动管理缓存中项的移除，但我们也可以通过代码编写的方式显式的移除相关的数据项：
Cache.Remove("First");
相对于应用程序缓存而言，页输出缓存的应用更为广泛。它可以通过内存将处理后的ASP.NET页面存储起来，当客户端再一次访问该页面时，可以省去页面处理的过程，从而提高页面访问的性能，以及Web服务器的吞吐量。例如，在一个电子商务网站里，用户需要经常查询商品信息，这个过程会涉及到数据库访问以及搜索条件的匹配，在数据量较大的情况下，如此的搜索过程是较为耗时的。此时，利用页输出缓存就可以将第一次搜索得到的查询结果页存储在缓存中。当用户第二次查询时，就可以省去数据查询的过程，减少页面的响应时间。
页输出缓存分为整页缓存和部分页缓存。我们可以通过@OutputCache指令完成对Web页面的输出缓存。它主要包含两个参数：Duration和VaryByParam。Duration参数用于设置页面或控件进行缓存的时间，其单位为秒。如下的设置表示缓存在60秒内有效：
<%@ OutputCache Duration=“60“ VaryByParam=“none“ %>
只要没有超过Duration设置的期限值，当用户访问相同的页面或控件时，就可以直接在缓存中获取。
使用VaryByParam参数可以根据设置的参数值建立不同的缓存。例如在一个输出天气预报结果的页面中，如果需要为一个ID为txtCity的TextBox控件建立缓存，其值将显示某城市的气温，那么我们可以进行如下的设置：
<%@ OutputCache Duration=”60” VaryByParam=”txtCity” %>
如此一来，ASP.NET会对txtCity控件的值进行判断，只有输入的值与缓存值相同，才从缓存中取出相应的值。这就有效地避免了因为值的不同而导致输出错误的数据。
利用缓存的机制对性能的提升非常明显。通过ACT（Application Center Test）的测试，可以发现设置缓存后执行的性能比未设置缓存时的性能足足提高三倍多。
引入缓存看来是提高性能的“完美”解决方案，然而“金无足赤，人无完人”，缓存机制也有缺点，那就是数据过期的问题。一旦应用程序数据或者页面结果值发生的改变，那么在缓存有效期范围内，你所获得的结果将是过期的、不准确的数据。我们可以想一想股票系统利用缓存所带来的灾难，当你利用错误过期的数据去分析股市的风云变幻时，你会发现获得的结果真可以说是“失之毫厘，谬以千里”，看似大好的局面就会像美丽的泡沫一样，用针一戳，转眼就消失得无影无踪。
那么我们是否应该为了追求高性能，而不顾所谓“数据过期”所带来的隐患呢？显然，在类似于股票系统这种数据更新频繁的特定场景下，数据过期的糟糕表现甚至比低效的性能更让人难以接受。故而，我们需要在性能与数据正确性间作出权衡。所幸的是，.Net Framework 2.0引入了一种新的缓存机制，它为我们的“鱼与熊掌兼得”带来了技术上的可行性。
.Net 2.0引入的自定义缓存依赖项，特别是基于MS-SQL Server的SqlCacheDependency特性，使得我们可以避免“数据过期”的问题，它能够根据数据库中相应数据的变化，通知缓存，并移除那些过期的数据。事实上，在PetShop 4.0中，就充分地利用了SqlCacheDependency特性。
4.2 SqlCacheDependency特性
SqlCacheDependency特性实际上是通过System.Web.Caching.SqlCacheDependency类来体现的。通过该类，可以在所有支持的SQL Server版本（7.0，2000，2005）上监视特定的SQL Server数据库表，并创建依赖于该表以及表中数据行的缓存项。当数据表或表中特定行的数据发生更改时，具有依赖项的数据项就会失效，并自动从Cache中删除该项，从而保证了缓存中不再保留过期的数据。
由于版本的原因，SQL Server 2005完全支持SqlCacheDependency特性，但对于SQL Server 7.0和SQL Server 2000而言，就没有如此幸运了。毕竟这些产品出现在.Net Framework 2.0之前，因此它并没有实现自动监视数据表数据变化，通知ASP.NET的功能。解决的办法就是利用轮询机制，通过ASP.NET进程内的一个线程以指定的时间间隔轮询SQL Server数据库，以跟踪数据的变化情况。
要使得7.0或者2000版本的SQL Server支持SqlCacheDependency特性，需要对数据库服务器执行相关的配置步骤。有两种方法配置SQL Server：使用aspnet_regsql命令行工具，或者使用SqlCacheDependencyAdmin类。
4.2.1 利用aspnet_regsql工具
aspnet_regsql工具位于Windows/Microsoft.NET/Framework/[版本]文件夹中。如果直接双击该工具的执行文件，会弹出一个向导对话框，提示我们完成相应的操作：
图4-1 aspnet_regsql工具
如图4-1所示中的提示信息，说明该向导主要用于配置SQL Server数据库，如membership，profiles等信息，如果要配置SqlCacheDependency，则需要以命令行的方式执行。以PetShop 4.0为例，数据库名为MSPetShop4，则命令为：
aspnet_regsql -S localhost -E -d MSPetShop4 -ed
以下是该工具的命令参数说明：
-? 显示该工具的帮助功能；
-S 后接的参数为数据库服务器的名称或者IP地址；
-U 后接的参数为数据库的登陆用户名；
-P 后接的参数为数据库的登陆密码；
-E 当使用windows集成验证时，使用该功能；
-d 后接参数为对哪一个数据库采用SqlCacheDependency功能；
-t 后接参数为对哪一个表采用SqlCacheDependency功能；
-ed 允许对数据库使用SqlCacheDependency功能；
-dd 禁止对数据库采用SqlCacheDependency功能；
-et 允许对数据表采用SqlCacheDependency功能；
-dt 禁止对数据表采用SqlCacheDependency功能；
-lt 列出当前数据库中有哪些表已经采用sqlcachedependency功能。
以上面的命令为例，说明将对名为MSPetShop4的数据库采用SqlCacheDependency功能，且SQL Server采用了windows集成验证方式。我们还可以对相关的数据表执行aspnet_regsql命令，如：
aspnet_regsql -S localhost -E -d MSPetShop4 -t Item -et
aspnet_regsql -S localhost -E -d MSPetShop4 -t Product -et
aspnet_regsql -S localhost -E -d MSPetShop4 -t Category -et
当执行上述的四条命令后，aspnet_regsql工具会在MSPetShop4数据库中建立一个名为AspNet_SqlCacheTablesForChangeNotification的新数据库表。该数据表包含三个字段。字段tableName记录要追踪的数据表的名称，例如在PetShop 4.0中，要记录的数据表就包括Category、Item和Product。notificationCreated字段记录开始追踪的时间。changeId作为一个类型为int的字段，用于记录数据表数据发生变化的次数。如图4-2所示：
图4-2 AspNet_SqlCacheTablesForChangeNotification数据表
除此之外，执行该命令还会为MSPetShop4数据库添加一组存储过程，为ASP.NET提供查询追踪的数据表的情况，同时还将为使用了SqlCacheDependency的表添加触发器，分别对应Insert、Update、Delete等与数据更改相关的操作。例如Product数据表的触发器：
Create TRIGGER dbo.[Product_AspNet_SqlCacheNotification_Trigger] ON [Product]
FOR Insert, Update, Delete AS BEGIN
SET NOCOUNT ON
EXEC dbo.AspNet_SqlCacheUpdateChangeIdStoredProcedure N'Product'
END
其中，AspNet_SqlCacheUpdateChangeIdStoredProcedure即是工具添加的一组存储过程中的一个。当对Product数据表执行Insert、Update或Delete等操作时，就会激活触发器，然后执行AspNet_SqlCacheUpdateChangeIdStoredProcedure存储过程。其执行的过程就是修改AspNet_SqlCacheTablesForChangeNotification数据表的changeId字段值：
Create PROCEDURE dbo.AspNet_SqlCacheUpdateChangeIdStoredProcedure
@tableName NVARCHAR(450)
AS
BEGIN
Update dbo.AspNet_SqlCacheTablesForChangeNotification WITH (ROWLOCK) SET changeId = changeId + 1
Where tableName = @tableName
END
GO
4.2.2 利用SqlCacheDependencyAdmin类
我们也可以利用编程的方式来来管理数据库对SqlCacheDependency特性的使用。该类包含了五个重要的方法：
| DisableNotifications |
为特定数据库禁用 SqlCacheDependency对象更改通知 |
| DisableTableForNotifications |
为数据库中的特定表禁用SqlCacheDependency对象更改通知 |
| EnableNotifications |
为特定数据库启用SqlCacheDependency对象更改通知 |
| EnableTableForNotifications |
为数据库中的特定表启用SqlCacheDependency对象更改通知 |
| GetTablesEnabledForNotifications |
返回启用了SqlCacheDependency对象更改通知的所有表的列表 |
表4-1 SqlCacheDependencyAdmin类的主要方法
假设我们定义了如下的数据库连接字符串：
const string connectionStr = "Server=localhost;Database=MSPetShop4";
那么为数据库MSPetShop4启用SqlCacheDependency对象更改通知的实现为：
protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
{
SqlCacheDependencyAdmin.EnableNotifications(connectionStr);
}
}
为数据表Product启用SqlCacheDependency对象更改通知的实现则为：
SqlCacheDependencyAdmin.EnableTableForNotifications(connectionStr, "Product");
如果要调用表4-1中所示的相关方法，需要注意的是访问SQL Server数据库的帐户必须具有创建表和存储过程的权限。如果要调用EnableTableForNotifications方法，还需要具有在该表上创建SQL Server触发器的权限。
虽然说编程方式赋予了程序员更大的灵活性，但aspnet_regsql工具却提供了更简单的方法实现对SqlCacheDependency的配置与管理。PetShop 4.0采用的正是aspnet_regsql工具的办法，它编写了一个文件名为InstallDatabases.cmd的批处理文件，其中包含了对aspnet_regsql工具的执行，并通过安装程序去调用该文件，实现对SQL Server的配置。
4.3 在PetShop 4.0中ASP.NET缓存的实现
PetShop作为一个B2C的宠物网上商店，需要充分考虑访客的用户体验，如果因为数据量大而导致Web服务器的响应不及时，页面和查询数据迟迟得不到结果，会因此而破坏客户访问网站的心情，在耗尽耐心的等待后，可能会失去这一部分客户。无疑，这是非常糟糕的结果。因而在对其进行体系架构设计时，整个系统的性能就显得殊为重要。然而，我们不能因噎废食，因为专注于性能而忽略数据的正确性。在PetShop 3.0版本以及之前的版本，因为ASP.NET缓存的局限性，这一问题并没有得到很好的解决。PetShop 4.0则引入了SqlCacheDependency特性，使得系统对缓存的处理较之以前大为改观。
4.3.1 CacheDependency接口
PetShop 4.0引入了SqlCacheDependency特性，对Category、Product和Item数据表对应的缓存实施了SQL Cache Invalidation技术。当对应的数据表数据发生更改后，该技术能够将相关项从缓存中移除。实现这一技术的核心是SqlCacheDependency类，它继承了CacheDependency类。然而为了保证整个架构的可扩展性，我们也允许设计者建立自定义的CacheDependency类，用以扩展缓存依赖。这就有必要为CacheDependency建立抽象接口，并在web.config文件中进行配置。
在PetShop 4.0的命名空间PetShop.ICacheDependency中，定义了名为IPetShopCacheDependency接口，它仅包含了一个接口方法：
public interface IPetShopCacheDependency
{
AggregateCacheDependency GetDependency();
}
AggregateCacheDependency是.Net Framework 2.0新增的一个类，它负责监视依赖项对象的集合。当这个集合中的任意一个依赖项对象发生改变时，该依赖项对象对应的缓存对象都将被自动移除。
AggregateCacheDependency类起到了组合CacheDependency对象的作用，它可以将多个CacheDependency对象甚至于不同类型的CacheDependency对象与缓存项建立关联。由于PetShop需要为Category、Product和Item数据表建立依赖项，因而IPetShopCacheDependency的接口方法GetDependency()其目的就是返回建立了这些依赖项的AggregateCacheDependency对象。
4.3.2 CacheDependency实现
CacheDependency的实现正是为Category、Product和Item数据表建立了对应的SqlCacheDependency类型的依赖项，如代码所示：
public abstract class TableDependency : IPetShopCacheDependency
{
// This is the separator that's used in web.config
protected char[] configurationSeparator = new char[] { ',' };
protected AggregateCacheDependency dependency = new AggregateCacheDependency();
protected TableDependency(string configKey)
{
string dbName = ConfigurationManager.AppSettings["CacheDatabaseName"];
string tableConfig = ConfigurationManager.AppSettings[configKey];
string[] tables = tableConfig.Split(configurationSeparator);
foreach (string tableName in tables)
dependency.Add(new SqlCacheDependency(dbName, tableName));
}
public AggregateCacheDependency GetDependency()
{
return dependency;
}
}
需要建立依赖项的数据库与数据表都配置在web.config文件中，其设置如下：
根据各个数据表间的依赖关系，因而不同的数据表需要建立的依赖项也是不相同的，从配置文件中的value值可以看出。然而不管建立依赖项的多寡，其创建的行为逻辑都是相似的，因而在设计时，抽象了一个共同的类TableDependency，并通过建立带参数的构造函数，完成对依赖项的建立。由于接口方法GetDependency()的实现中，返回的对象dependency是在受保护的构造函数创建的，因此这里的实现方式也可以看作是Template Method模式的灵活运用。例如TableDependency的子类Product，就是利用父类的构造函数建立了Product、Category数据表的SqlCacheDependency依赖：
public class Product : TableDependency
{
public Product() : base("ProductTableDependency") { }
}
如果需要自定义CacheDependency，那么创建依赖项的方式又有不同。然而不管是创建SqlCacheDependency对象，还是自定义的CacheDependency对象，都是将这些依赖项添加到AggregateCacheDependency类中，因而我们也可以为自定义CacheDependency建立专门的类，只要实现IPetShopCacheDependency接口即可。
4.3.3 CacheDependency工厂
继承了抽象类TableDependency的Product、Category和Item类均需要在调用时创建各自的对象。由于它们的父类TableDependency实现了接口IPetShopCacheDependency，因而它们也间接实现了IPetShopCacheDependency接口，这为实现工厂模式提供了前提。
在PetShop 4.0中，依然利用了配置文件和反射技术来实现工厂模式。命名空间PetShop.CacheDependencyFactory中，类DependencyAccess即为创建IPetShopCacheDependency对象的工厂类：
public static class DependencyAccess
{
public static IPetShopCacheDependency CreateCategoryDependency()
{
return LoadInstance("Category");
}
public static IPetShopCacheDependency CreateProductDependency()
{
return LoadInstance("Product");
}
public static IPetShopCacheDependency CreateItemDependency()
{
return LoadInstance("Item");
}
private static IPetShopCacheDependency LoadInstance(string className)
{
string path = ConfigurationManager.AppSettings["CacheDependencyAssembly"];
string fullyQualifiedClass = path + "." + className;
return (IPetShopCacheDependency)Assembly.Load(path).CreateInstance(fullyQualifiedClass);
}
}
整个工厂模式的实现如图4-3所示：
图4-3 CacheDependency工厂
虽然DependencyAccess类创建了实现了IPetShopCacheDependency接口的类Category、Product、Item，然而我们之所以引入IPetShopCacheDependency接口，其目的就在于获得创建了依赖项的AggregateCacheDependency类型的对象。我们可以调用对象的接口方法GetDependency()，如下所示：
AggregateCacheDependency dependency = DependencyAccess.CreateCategoryDependency().GetDependency();
为了方便调用者，似乎我们可以对DependencyAccess类进行改进，将原有的CreateCategoryDependency()方法，修改为创建AggregateCacheDependency类型对象的方法。
然而这样的做法扰乱了作为工厂类的DependencyAccess的本身职责，且创建IPetShopCacheDependency接口对象的行为仍然有可能被调用者调用，所以保留原有的DependencyAccess类仍然是有必要的。
在PetShop 4.0的设计中，是通过引入Facade模式以方便调用者更加简单地获得AggregateCacheDependency类型对象。
4.3.4 引入Facade模式
利用Facade模式可以将一些复杂的逻辑进行包装，以方便调用者对这些复杂逻辑的调用。就好像提供一个统一的门面一般，将内部的子系统封装起来，统一为一个高层次的接口。一个典型的Facade模式示意图如下所示：
图4-4 Facade模式
Facade模式的目的并非要引入一个新的功能，而是在现有功能的基础上提供一个更高层次的抽象，使得调用者可以直接调用，而不用关心内部的实现方式。以CacheDependency工厂为例，我们需要为调用者提供获得AggregateCacheDependency对象的简便方法，因而创建了DependencyFacade类：
public static class DependencyFacade
{
private static readonly string path = ConfigurationManager.AppSettings["CacheDependencyAssembly"];
public static AggregateCacheDependency GetCategoryDependency()
{
if (!string.IsNullOrEmpty(path))
return DependencyAccess.CreateCategoryDependency().GetDependency();
else
return null;
}
public static AggregateCacheDependency GetProductDependency()
{
if (!string.IsNullOrEmpty(path))
return DependencyAccess.CreateProductDependency().GetDependency();
else
return null;
}
public static AggregateCacheDependency GetItemDependency()
{
if (!string.IsNullOrEmpty(path))
return DependencyAccess.CreateItemDependency().GetDependency();
else
return null;
}
}
DependencyFacade类封装了获取AggregateCacheDependency类型对象的逻辑，如此一来，调用者可以调用相关方法获得创建相关依赖项的AggregateCacheDependency类型对象：
AggregateCacheDependency dependency = DependencyFacade.GetCategoryDependency();
比起直接调用DependencyAccess类的GetDependency()方法而言，除了方法更简单之外，同时它还对CacheDependencyAssembly配置节进行了判断，如果其值为空，则返回null对象。
在PetShop.Web的App_Code文件夹下，静态类WebUtility的GetCategoryName()和GetProductName()方法调用了DependencyFacade类。例如GetCategoryName()方法：
public static string GetCategoryName(string categoryId)
{
Category category = new Category();
if (!enableCaching)
return category.GetCategory(categoryId).Name;
string cacheKey = string.Format(CATEGORY_NAME_KEY, categoryId);
// 检查缓存中是否存在该数据项;
string data = (string)HttpRuntime.Cache[cacheKey];
if (data == null)
{
// 通过web.config的配置获取duration值;
int cacheDuration = int.Parse(ConfigurationManager.AppSettings["CategoryCacheDuration"]);
// 如果缓存中不存在该数据项，则通过业务逻辑层访问数据库获取;
data = category.GetCategory(categoryId).Name;
// 通过Facade类创建AggregateCacheDependency对象;
AggregateCacheDependency cd = DependencyFacade.GetCategoryDependency();
// 将数据项以及AggregateCacheDependency 对象存储到缓存中;
HttpRuntime.Cache.Add(cacheKey, data, cd, DateTime.Now.AddHours(cacheDuration), Cache.NoSlidingExpiration, CacheItemPriority.High, null);
}
return data;
}
GetCategoryName()方法首先会检查缓存中是否已经存在CategoryName数据项，如果已经存在，就通过缓存直接获取数据；否则将通过业务逻辑层调用数据访问层访问数据库获得CategoryName，在获得了CategoryName后，会将新获取的数据连同DependencyFacade类创建的AggregateCacheDependency对象添加到缓存中。
WebUtility静态类被表示层的许多页面所调用，例如Product页面：
public partial class Products : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
Page.Title = WebUtility.GetCategoryName(Request.QueryString["categoryId"]);
}
}
显示页面title的逻辑是放在Page_Load事件方法中，因而每次打开该页面都要执行获取CategoryName的方法。如果没有采用缓存机制，当Category数据较多时，页面的显示就会非常缓慢。
4.3.5 引入Proxy模式
业务逻辑层BLL中与Product、Category、Item有关的业务方法，其实现逻辑是调用数据访问层（DAL）对象访问数据库，以获取相关数据。为了改善系统性能，我们就需要为这些实现方法增加缓存机制的逻辑。当我们操作增加了缓存机制的业务对象时，对于调用者而言，应与BLL业务对象的调用保持一致。也即是说，我们需要引入一个新的对象去控制原来的BLL业务对象，这个新的对象就是Proxy模式中的代理对象。
以PetShop.BLL.Product业务对象为例，PetShop为其建立了代理对象ProductDataProxy，并在GetProductByCategory()等方法中，引入了缓存机制，例如：
public static class ProductDataProxy
{
private static readonly int productTimeout = int.Parse(ConfigurationManager.AppSettings["ProductCacheDuration"]);
private static readonly bool enableCaching = bool.Parse(ConfigurationManager.AppSettings["EnableCaching"]);
public static IList
GetProductsByCategory(string category)
{
Product product = new Product();
if (!enableCaching)
return product.GetProductsByCategory(category);
string key = "product_by_category_" + category;
IList data = (IList )HttpRuntime.Cache[key];
// Check if the data exists in the data cache
if (data == null)
{
data = product.GetProductsByCategory(category);
// Create a AggregateCacheDependency object from the factory
AggregateCacheDependency cd = DependencyFacade.GetProductDependency();
// Store the output in the data cache, and Add the necessary AggregateCacheDependency object
HttpRuntime.Cache.Add(key, data, cd, DateTime.Now.AddHours(productTimeout), Cache.NoSlidingExpiration, CacheItemPriority.High, null);
}
return data;
}
}
与业务逻辑层Product对象的GetProductsByCategory()方法相比，增加了缓存机制。当缓存内不存在相关数据项时，则直接调用业务逻辑层Product的GetProductsByCategory()方法来获取数据，并将其与对应的AggregateCacheDependency对象一起存储在缓存中。
引入Proxy模式，实现了在缓存级别上对业务对象的封装，增强了对业务对象的控制。由于暴露在对象外的方法是一致的，因而对于调用方而言，调用代理对象与真实对象并没有实质的区别。
从职责分离与分层设计的角度分析，我更希望这些Proxy对象是被定义在业务逻辑层中，而不像在PetShop的设计那样，被划分到表示层UI中。此外，如果需要考虑程序的可扩展性与可替换性，我们还可以为真实对象与代理对象建立统一的接口或抽象类。然而，单以PetShop的表示层调用来看，采用静态类与静态方法的方式，或许更为合理。我们需要谨记，“过度设计”是软件设计的警戒线。
如果需要对UI层采用缓存机制，将应用程序数据存放到缓存中，就可以调用这些代理对象。以ProductsControl用户控件为例，调用方式如下：
productsList.DataSource = ProductDataProxy.GetProductsByCategory(categoryKey);
productsList对象属于自定义的CustomList类型，这是一个派生自System.Web.UI.WebControls.DataList控件的类，它的DataSource属性可以接受IList集合对象。
不过在PetShop 4.0的设计中，对于类似于ProductsControl类型的控件而言，采用的缓存机制是页输出缓存。我们可以从ProductsControl.ascx页面的Source代码中发现端倪：
<%@ OutputCache Duration="100000" VaryByParam="page;categoryId" %>
与ASP.NET 1.x的页输出缓存不同的是，在ASP.NET 2.0中，为ASP.NET用户控件新引入了CachePolicy属性，该属性的类型为ControlCachePolicy类，它以编程方式实现了对ASP.NET用户控件的输出缓存设置。我们可以通过设置ControlCachePolicy类的Dependency属性，来设置与该用户控件相关的依赖项，例如在ProductsControl用户控件中，进行如下的设置：
protected void Page_Load(object sender, EventArgs e)
{
this.CachePolicy.Dependency = DependencyFacade.GetProductDependency();
}
采用页输出缓存，并且利用ControlCachePolicy设置输出缓存，能够将业务数据与整个页面放入到缓存中。这种方式比起应用程序缓存而言，在性能上有很大的提高。同时，它又通过引入的SqlCacheDependency特性有效地避免了“数据过期”的缺点，因而在PetShop 4.0中被广泛采用。相反，之前为Product、Category、Item业务对象建立的代理对象则被“投闲散置”，仅仅作为一种设计方法的展示而“幸存”与整个系统的源代码中。
五 PetShop之业务逻辑层设计
业务逻辑层（Business Logic Layer）无疑是系统架构中体现核心价值的部分。它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计，也即是说它是与系统所应对的领域（Domain）逻辑有关，很多时候，我们也将业务逻辑层称为领域层。例如Martin Fowler在《Patterns of Enterprise Application Architecture》一书中，将整个架构分为三个主要的层：表示层、领域层和数据源层。作为领域驱动设计的先驱Eric Evans，对业务逻辑层作了更细致地划分，细分为应用层与领域层，通过分层进一步将领域逻辑与领域逻辑的解决方案分离。
业务逻辑层在体系架构中的位置很关键，它处于数据访问层与表示层中间，起到了数据交换中承上启下的作用。由于层是一种弱耦合结构，层与层之间的依赖是向下的，底层对于上层而言是“无知”的，改变上层的设计对于其调用的底层而言没有任何影响。如果在分层设计时，遵循了面向接口设计的思想，那么这种向下的依赖也应该是一种弱依赖关系。因而在不改变接口定义的前提下，理想的分层式架构，应该是一个支持可抽取、可替换的“抽屉”式架构。正因为如此，业务逻辑层的设计对于一个支持可扩展的架构尤为关键，因为它扮演了两个不同的角色。对于数据访问层而言，它是调用者；对于表示层而言，它却是被调用者。依赖与被依赖的关系都纠结在业务逻辑层上，如何实现依赖关系的解耦，则是除了实现业务逻辑之外留给设计师的任务。
5.1 与领域专家合作
设计业务逻辑层最大的障碍不在于技术，而在于对领域业务的分析与理解。很难想象一个不熟悉该领域业务规则和流程的架构设计师能够设计出合乎客户需求的系统架构。几乎可以下定结论的是，业务逻辑层的设计过程必须有领域专家的参与。在我曾经参与开发的项目中，所涉及的领域就涵盖了电力、半导体、汽车等诸多行业，如果缺乏这些领域的专家，软件架构的设计尤其是业务逻辑层的设计就无从谈起。这个结论唯一的例外是，架构设计师同时又是该领域的专家。然而，正所谓“千军易得，一将难求”，我们很难寻觅到这样卓越出众的人才。
领域专家在团队中扮演的角色通常称为Business Consultor（业务咨询师），负责提供与领域业务有关的咨询，与架构师一起参与架构与数据库的设计，撰写需求文档和设计用例（或者用户故事User Story）。如果在测试阶段，还应该包括撰写测试用例。理想的状态是，领域专家应该参与到整个项目的开发过程中，而不仅仅是需求阶段。
领域专家可以是专门聘请的对该领域具有较深造诣的咨询师，也可以是作为需求提供方的客户。在极限编程（Extreme Programming）中，就将客户作为领域专家引入到整个开发团队中。它强调了现场客户原则。现场客户需要参与到计划游戏、开发迭代、编码测试等项目开发的各个阶段。由于领域专家与设计师以及开发人员组成了一个团队，贯穿开发过程的始终，就可以避免需求理解错误的情况出现。即使项目的开发与实际需求不符，也可以在项目早期及时修正，从而避免了项目不必要的延期，加强了对项目过程和成本的控制。正如Steve McConnell在构建活动的前期准备中提及的一个原则：发现错误的时间要尽可能接近引入该错误的时间。需求的缺陷在系统中潜伏的时间越长，代价就越昂贵。如果在项目开发中能够与领域专家充分的合作，就可以最大效果地规避这样一种恶性的链式反应。
传统的软件开发模型同样重视与领域专家的合作，但这种合作主要集中在需求分析阶段。例如瀑布模型，就非常强调早期计划与需求调研。然而这种未雨绸缪的早期计划方式，对架构师与需求调研人员的技能要求非常高，它强调需求文档的精确性，一旦分析出现偏差，或者需求发生变更，当项目开发进入设计阶段后，由于缺乏与领域专家沟通与合作的机制，开发人员估量不到这些错误与误差，因而难以及时作出修正。一旦这些问题像毒瘤一般在系统中蔓延开来，逐渐暴露在开发人员面前时，已经成了一座难以逾越的高山。我们需要消耗更多的人力物力，才能够修正这些错误，从而导致开发成本成数量级的增加，甚至于导致项目延期。当然还有一个好的选择，就是放弃整个项目。这样的例子不胜枚举，事实上，项目开发的“滑铁卢”，究其原因，大部分都是因为业务逻辑分析上出现了问题。
迭代式模型较之瀑布模型有很大地改进，因为它允许变更、优化系统需求，整个迭代过程实际上就是与领域专家的合作过程，通过向客户演示迭代所产生的系统功能，从而及时获取反馈，并逐一解决迭代演示中出现的问题，保证系统向着合乎客户需求的方向演化。因而，迭代式模型往往能够解决早期计划不足的问题，它允许在发现缺陷的时候，在需求变更的时候重新设计、重新编码并重新测试。
无论采用何种开发模型，与领域专家的合作都将成为项目成败与否的关键。这基于一个软件开发的普遍真理，那就是世界上没有不变的需求。一句经典名言是：“没有不变的需求，世上的软件都改动过3次以上，唯一一个只改动过两次的软件的拥有者已经死了，死在去修改需求的路上。”一语道尽了软件开发的残酷与艰辛！
那么应该如何加强与领域专家的合作呢？James Carey和Brent Carlson根据他们在参与的IBM SanFrancisco项目中获得的经验，提出了Innocent Questions模式，其意义即“改进领域专家和技术专家的沟通质量”。在一个项目团队中，如果我们没有一位既能担任首席架构师，同时又是领域专家的人选，那么加强领域专家与技术专家的合作就显得尤为重要了。毕竟，作为一个领域专家而言，可能并不熟悉软件设计方法学，也不具备面向对象开发和架构设计的能力，同样，大部分技术专家很有可能对该项目所涉及的业务领域仅停留在一知半解的地步。如果领域专家与技术专家不能有效沟通，则整个项目的前途就岌岌可危了。
Innocent Questions模式提出的解决方案包括：
（1）选用可以与人和谐相处的人员组建开发团队；
（2）清楚地定义角色和职权；
（3）明确定义需要的交互点；
（4）保持团队紧密；
（5）雇佣优秀的人。
事实上，这已经从技术的角度上升到对团队的管理层次了。就好比篮球运动一样，即使你的球队集合了五名世界上最顶尖最有天赋的球员，如果各自为战，要想取得比赛的胜利依旧是非常困难的。团队精神与权责分明才是取得胜利的保障，软件开发同样如此。
与领域专家合作的基础是保证开发团队中永远保留至少一名领域专家。他可以是系统的客户，第三方公司的咨询师，最理想是自己公司雇佣的专家。如果项目中缺乏这样的一个人，那么我的建议是去雇佣他，如果你不想看到项目遭遇“西伯利亚寒流”的话。
确定领域专家的角色任务与职责。必须要让团队中的每一个人明确领域专家在整个团队中究竟扮演什么样的角色，他的职责是什么。一个合格的领域专家必须对业务领域有足够深入的理解，他应该是一个能够俯瞰整个系统需求、总揽全局的人物。在项目开发过程中，将由他负责业务规则和流程的制定，负责与客户的沟通，需求的调研与讨论，并于设计师一起参与系统架构的设计。编档是领域专家必须参与的工作，无论是需求文档还是设计文档，以及用例的编写，领域专家或者提出意见，或者作为撰写的作者，至少他也应该是评审委员会的重要成员。
规范业务领域的术语和技术术语。领域专家和技术专家必须在保证不产生二义性的语义环境下进行沟通与交流。如果出现理解上的分歧，我们必须及时解决，通过讨论确立术语标准。很难想象两个语言不通的人能够相互合作愉快，解决的办法是加入一位翻译人员。在领域专家与技术专家之间搭建一座语义上的桥梁，使其能够相互理解、相互认同。还有一个办法是在团队内部开展培训活动。尤其对于开发人员而言，或多或少地了解一些业务领域知识，对于项目的开发有很大的帮助。在我参与过的半导体领域的项目开发，团队就专门邀请了半导体行业的专家就生产过程的业务逻辑进行了全方位的介绍与培训。正所谓“磨刀不误砍柴工”，虽然我们消费了培训的时间，但对于掌握了业务规则与流程的开发人员，却能够提升项目开发进度，总体上节约了开发成本。
加强与客户的沟通。客户同时也可以作为团队的领域专家，极限编程的现场客户原则是最好的示例。但现实并不都如此的完美，在无法要求客户成为开发团队中的固定一员时，聘请或者安排一个专门的领域专家，加强与客户的沟通，就显得尤为重要。项目可以通过领域专家获得客户的及时反馈。而通过领域专家去了解变更了的需求，会在最大程度上减少需求误差的可能。
5.2 业务逻辑层的模式应用
Martin Fowler在《企业应用架构模式》一书中对领域层（即业务逻辑层）的架构模式作了整体概括，他将业务逻辑设计分为三种主要的模式：Transaction Script、Domain Model和Table Module。
Transaction Script模式将业务逻辑看作是一个个过程，是比较典型的面向过程开发模式。应用Transaction Script模式可以不需要数据访问层，而是利用SQL语句直接访问数据库。为了有效地管理SQL语句，可以将与数据库访问有关的行为放到一个专门的Gateway类中。应用Transaction Script模式不需要太多面向对象知识，简单直接的特性是该模式全部价值之所在。因而，在许多业务逻辑相对简单的项目中，应用Transaction Script模式较多。
Domain Model模式是典型的面向对象设计思想的体现。它充分考虑了业务逻辑的复杂多变，引入了Strategy模式等设计模式思想，并通过建立领域对象以及抽象接口，实现模式的可扩展性，并利用面向对象思想与身俱来的特性，如继承、封装与多态，用于处理复杂多变的业务逻辑。唯一制约该模式应用的是对象与关系数据库的映射。我们可以引入ORM工具，或者利用Data Mapper模式来完成关系向对象的映射。
与Domain Model模式相似的是Table Module模式，它同样具有面向对象设计的思想，唯一不同的是它获得的对象并非是单纯的领域对象，而是DataSet对象。如果为关系数据表与对象建立一个简单的映射关系，那么Domain Model模式就是为数据表中的每一条记录建立一个领域对象，而Table Module模式则是将整个数据表看作是一个完整的对象。虽然利用DataSet对象会丢失面向对象的基本特性，但它在为表示层提供数据源支持方面却有着得天独厚的优势。尤其是在.Net平台下，ADO.NET与Web控件都为Table Module模式提供了生长的肥沃土壤。
5.3 PetShop的业务逻辑层设计
PetShop在业务逻辑层设计中引入了Domain Model模式，这与数据访问层对于数据对象的支持是分不开的。由于PetShop并没有对宠物网上商店的业务逻辑进行深入，也省略了许多复杂细节的商务逻辑，因而在Domain Model模式的应用上并不明显。最典型地应该是对Order领域对象的处理方式，通过引入Strategy模式完成对插入订单行为的封装。关于这一点，我已在第27章有了详尽的描述，这里就不再赘述。
本应是系统架构设计中最核心的业务逻辑层，由于简化了业务流程的缘故，使得PetShop在这一层的设计有些乏善可陈。虽然在业务逻辑层中，针对B2C业务定义了相关的领域对象，但这些领域对象仅仅是完成了对数据访问层中数据对象的简单封装而已，其目的仅在于分离层次，以支持对各种数据库的扩展，同时将SQL语句排除在业务逻辑层外，避免了SQL语句的四处蔓延。
最能体现PetShop业务逻辑的除了对订单的管理之外，还包括购物车（Shopping Cart）与Wish List的管理。在PetShop的BLL模块中，定义了Cart类来负责相关的业务逻辑，定义如下：
[Serializable]
public class Cart
{
private Dictionary cartItems = new Dictionary ();
public decimal Total
{
get
{
decimal total = 0;
foreach (CartItemInfo item in cartItems.Values)
total += item.Price * item.Quantity;
return total;
}
}
public void SetQuantity(string itemId, int qty)
{
cartItems[itemId].Quantity = qty;
}
public int Count
{
get { return cartItems.Count; }
}
public void Add(string itemId)
{
CartItemInfo cartItem;
if (!cartItems.TryGetValue(itemId, out cartItem))
{
Item item = new Item();
ItemInfo data = item.GetItem(itemId);
if (data != null)
{
CartItemInfo newItem = new CartItemInfo(itemId, data.ProductName, 1, (decimal)data.Price, data.Name, data.CategoryId, data.ProductId);
cartItems.Add(itemId, newItem);
}
}
else
cartItem.Quantity++;
}
//其他方法略;
}
Cart类通过一个Dictionary对象来负责对购物车内容的存储，同时定义了Add、Remove、Clear等方法，来实现对购物车内容的管理。
在前面我提到PetShop业务逻辑层中的领域对象仅仅是完成对数据对象的简单封装，但这种分离层次的方法在架构设计中依然扮演了举足轻重的作用。以Cart类的Add()方法为例，在方法内部引入了PetShop.BLL.Item领域对象，并调用了Item对象的GetItem()方法。如果没有在业务逻辑层封装Item对象，而是直接调用数据访问层的Item数据对象，为保证层次间的弱依赖关系，就需要调用工厂对象的工厂方法来创建PetShop.IDAL.IItem接口类型对象。一旦数据访问层的Item对象被多次调用，就会造成重复代码，既不离于程序的修改与扩展，也导致程序结构生长为臃肿的态势。
此外，领域对象对数据访问层数据对象的封装，也有利于表示层对业务逻辑层的调用。在三层式架构中，表示层应该是对于数据访问层是“无知”的，这样既减少了层与层间的依赖关系，也能有效避免“循环依赖”的后果。
值得商榷的是Cart类的Total属性。其值的获取是通过遍历购物车集合，然后累加价格与商品数量的乘积。这里显然简化了业务逻辑，而没有充分考虑需求的扩展。事实上，这种获取购物车总价格的算法，在大多数情况下仅仅是其中的一种策略而已，我们还应该考虑折扣的情况。例如，当总价格超过100元时，可以给与顾客一定的折扣，这是与网站的促销计划相关的。除了给与折扣的促销计划外，网站也可以考虑赠送礼品的促销策略，因此我们有必要引入Strategy模式，定义接口IOnSaleStrategy：
public interface IOnSaleStrategy
{
decimal CalculateTotalPrice(Dictionary cartItems);
}
如此一来，我们可以为Cart类定义一个有参数的构造函数：
private IOnSaleStrategy m_onSale;
public Cart(IOnSaleStrategy onSale)
{
m_onSale = onSale;
}
那么Total属性就可以修改为：
public decimal Total
{
get {return m_onSale.CalculateTotalPrice(cartItems);}
}
如此一来，就可以使得Cart类能够有效地支持网站推出的促销计划，也符合开-闭原则。同样的，这种设计方式也是Domain Model模式的体现。修改后的设计如图5-1所示：
图5-1 引入Strategy模式
作为一个B2C的电子商务架构，它所涉及的业务领域已为大部分设计师与开发人员所熟悉，因而在本例中，与领域专家的合作显得并不那么重要。然而，如果我们要开发一个成功的电子商务网站，与领域专家的合作仍然是必不可少的。以订单的管理而言，如果考虑复杂的商业应用，就需要管理订单的跟踪（Tracking），与网上银行的合作，账户安全性，库存管理，物流管理，以及客户关系管理（CRM）。整个业务过程却涵盖了诸如电子商务、银行、物流、客户关系学等诸多领域，如果没有领域专家的参与，业务逻辑层的设计也许会“败走麦城”。
5.4 与数据访问层的通信
业务逻辑层需要与数据访问层通信，利用数据访问层访问数据库，因此业务逻辑层与数据访问层之间就存在依赖关系。在数据访问层引入接口程序集以及数据工厂的设计前提下，能够做到两者间关系为弱依赖。我们从业务逻辑层的引用程序集中可以看到，BLL模块并没有引用SQLServerDAL和OracleDAL程序集。在业务逻辑层中，有关数据访问层中数据对象的调用，均利用多态原理定义了抽象的接口类型对象，然后利用工厂对象的工厂方法创建具体的数据对象。如PetShop.BLL.PetShop领域对象所示：
namespace PetShop.BLL
{
public class Product
{
//根据工厂对象创建IProduct接口类型实例;
private static readonly IProduct dal = PetShop.DALFactory.DataAccess.CreateProduct();
//调用IProduct对象的接口方法GetProductByCategory();
public IList
GetProductsByCategory(string category)
{
// 如果为空则新建List对象;
if(string.IsNullOrEmpty(category))
return new List ();
// 通过数据访问层的数据对象访问数据库;
return dal.GetProductsByCategory(category);
}
//其他方法略;
}
}
在领域对象Product类中，利用数据访问层的工厂类DALFactory.DataAccess创建PetShop.IDAL.IProduct类型的实例，如此就可以解除对具体程序集SQLServerDAL或OracleDAL的依赖。只要PetShop.IDAL的接口方法不变，即使修改了IDAL接口模块的具体实现，都不会影响业务逻辑层的实现。这种松散的弱耦合关系，才能够最大程度地支持架构的可扩展。
领域对象Product实际上还完成了对数据对象Product的封装，它们暴露在外的接口方法是一致地，正是通过封装，使得表示层可以完全脱离数据库以及数据访问层，表示层的调用者仅需要关注业务逻辑层的实现逻辑，以及领域对象暴露的接口和调用方式。事实上，只要设计合理，规范了各个层次的接口方法，三层式架构的设计完全可以分离开由不同的开发人员同时开发，这就可以有效地利用开发资源，缩短项目开发周期。
5.5 面向接口设计
也许是业务逻辑比较简单地缘故，在业务逻辑层的设计中，并没有秉承在数据访问层中面向接口设计的思想。除了完成对插入订单策略的抽象外，整个业务逻辑层仅以BLL模块实现，没有为领域对象定义抽象的接口。因而PetShop的表示层与业务逻辑层就存在强依赖关系，如果业务逻辑层中的需求发生变更，就必然会影响表示层的实现。唯一可堪欣慰的是，由于我们采用分层式架构将用户界面与业务领域逻辑完全分离，一旦用户界面发生更改，例如将B/S架构修改为C/S架构，那么业务逻辑层的实现模块是可以完全重用的。
然而，最理想的方式仍然是面向接口设计。根据第28章对ASP.NET缓存的分析，我们可以将表示层App_Code下的Proxy类与Utility类划分到业务逻辑层中，并修改这些静态类为实例类，并将这些类中与业务领域有关的方法抽象为接口，然后建立如数据访问层一样的抽象工厂。通过“依赖注入”方式，解除与具体领域对象类的依赖，使得表示层仅依赖于业务逻辑层的接口程序集以及工厂模块。
那么，这样的设计是否有“过度设计”的嫌疑呢？我们需要依据业务逻辑的需求情况而定。此外，如果我们需要引入缓存机制，为领域对象创建代理类，那么为领域对象建立接口，就显得尤为必要。我们可以建立一个专门的接口模块IBLL，用以定义领域对象的接口。以Product领域对象为例，我们可以建立IProduct接口：
public interface IProduct
{
IList GetProductByCategory(string category);
IList GetProductByCategory(string[] keywords);
ProductInfo GetProduct(string productId);
}
在BLL模块中可以引入对IBLL程序集的依赖，则领域对象Product的定义如下：
public class Product:IProduct
{
public IList GetProductByCategory(string category) { //实现略; }
public IList GetProductByCategory(string[] keywords) { //实现略; }
public ProductInfo GetProduct(string productId) { //实现略; }
}
然后我们可以为代理对象建立专门的程序集BLLProxy，它不仅引入对IBLL程序集的依赖，同时还将依赖于BLL程序集。此时代理对象ProductDataProxy的定义如下：
using PetShop.IBLL;
using PetShop.BLL;
namespace PetShop.BLLProxy
{
public class ProductDataProxy:IProduct
{
public IList GetProductByCategory(string category)
{
Product product = new Product();
//其他实现略;
}
public IList GetProductByCategory(string[] keywords) { //实现略; }
public ProductInfo GetProduct(string productId) { //实现略; }
}
}
如此的设计正是典型的Proxy模式，其类结构如图5-2所示：
图5-2 Proxy模式
参照数据访问层的设计方法，我们可以为领域对象及代理对象建立抽象工厂，并在web.config中配置相关的配置节，然后利用反射技术创建具体的对象实例。如此一来，表示层就可以仅仅依赖PetShop.IBLL程序集以及工厂模块，如此就可以解除表示层与具体领域对象之间的依赖关系。表示层与修改后的业务逻辑层的关系如图5-3所示：
图5-3 修改后的业务逻辑层与表示层的关系
图5-4则是PetShop 4.0原有设计的层次关系图：
图5-4 PetShop 4.0中表示层与业务逻辑层的关系
通过比较图5-3与图5-4，虽然后者不管是模块的个数，还是模块之间的关系，都相对更加简单，然而Web Component组件与业务逻辑层之间却是强耦合的，这样的设计不利于应对业务扩展与需求变更。通过引入接口模块IBLL与工厂模块BLLFactory，解除了与具体模块BLL的依赖关系。这种设计对于业务逻辑相对比较复杂的系统而言，更符合面向对象的设计思想，有利于我们建立可抽取、可替换的“抽屉”式三层架构。
《解剖PetShop》系列之六
六 PetShop之表示层设计
表示层（Presentation Layer）的设计可以给系统客户最直接的体验和最十足的信心。正如人与人的相交相识一样，初次见面的感觉总是永难忘怀的。一件交付给客户使用的产品，如果在用户界面（User Interface，UI）上缺乏吸引人的特色，界面不友好，操作不够体贴，即使这件产品性能非常优异，架构设计合理，业务逻辑都满足了客户的需求，却仍然难以讨得客户的欢心。俗语云：“佛要金装，人要衣装”，特别是对于Web应用程序而言，Web网页就好比人的衣装，代表着整个系统的身份与脸面，是招徕“顾客”的最大卖点。
“献丑不如藏拙”，作为艺术细胞缺乏的我，并不打算在用户界面的美术设计上大做文章，是以本书略过不提。本章所关注的表示层设计，还是以架构设计的角度，阐述在表示层设计中对模式的应用，ASP.NET控件的设计与运用，同时还包括了对ASP.NET 2.0新特色的介绍。
6.1 MVC模式
表示层设计中最重要的模式是MVC（Model-View-Controller，即模型-视图-控制器）模式。MVC模式最早是由SmallTalk语言研究团提出的，被广泛应用在用户交互应用程序中。Controller根据用户请求（Response）修改Model的属性，此时Event（事件）被触发，所有依赖于Model的View对象会自动更新，并基于Model对象产生一个响应（Response）信息，返回给Controller。Martin Fowler在《企业应用架构模式》一书中，展示了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.2 Page Controller模式的应用
通观PetShop的表示层设计，充分利用了ASP.NET的技术特点，通过Web页面与用户控件控制和展现视图，并利用codebehind技术将业务逻辑层的领域对象加入到表示层实现逻辑中，一个典型的Page Controller模式呼之欲出。
Page Controller模式是Martin Fowler在《企业应用架构模式》中最重要的表示层模式之一。在.NET平台下，Page Controller模式的实现非常简单，以Products.aspx页面为例。首先在aspx页面中，进行如下的设置：
<%
@ Page AutoEventWireup
=
"
true
"
Language
=
"
C#
"
MasterPageFile
=
"
~/MasterPage.master
"
Title
=
"
Products
"
Inherits
=
"
PetShop.Web.Products
"
CodeFile
=
"
~/Products.aspx.cs
"
%>
Aspx页面继承自System.Web.UI.Page类。Page类对象通过继承System.Web.UI.Control类，从而拥有了Web控件的特性，同时它还实现了IHttpHandler接口。作为ASP.NET处理HTTP Web请求的接口，提供了如下的定义：
[AspNetHostingPermission(SecurityAction.InheritanceDemand, Level
=
AspNetHostingPermissionLevel.Minimal), AspNetHostingPermission(SecurityAction.LinkDemand, Level
=
AspNetHostingPermissionLevel.Minimal)]
public
interface
IHttpHandler
{
void ProcessRequest(HttpContext context);
bool IsReusable { get; }
}
Page类实现了ProcessRequest()方法，通过它可以设置Page对象的Request和Response属性，从而完成对用户请求/相应的控制。然后Page类通过从Control类继承来的Load事件，将View与Model建立关联，如Products.aspx.cs所示：
public
partial
class
Products : System.Web.UI.Page
{ protected void Page_Load(object sender, EventArgs e) { //get page header and title Page.Title = WebUtility.GetCategoryName(Request.QueryString["categoryId"]);
}}
事件机制恰好是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()方法，如下所示：
public
partial
class
CheckOut : System.Web.UI.Page
protected
void
wzdCheckOut_FinishButtonClick(
object
sender, WizardNavigationEventArgs e)
{ if (Profile.ShoppingCart.CartItems.Count > 0) { if (Profile.ShoppingCart.Count > 0) { // display ordered items CartListOrdered.Bind(Profile.ShoppingCart.CartItems); // display total and credit card information ltlTotalComplete.Text = ltlTotal.Text; ltlCreditCardComplete.Text = ltlCreditCard.Text; // create order OrderInfo order = new OrderInfo(int.MinValue, DateTime.Now, User.Identity.Name, GetCreditCardInfo(), billingForm.Address, shippingForm.Address, Profile.ShoppingCart.Total, Profile.ShoppingCart.GetOrderLineItems(), null); // insert Order newOrder = new Order(); newOrder.Insert(order); // destroy cart Profile.ShoppingCart.Clear(); Profile.Save(); } } else { lblMsg.Text = "
Can not process the order. Your cart is empty.
wzdCheckOut.Visible = false; } }
在上面的一段代码中，非常典型地表达了Model与View之间的关系。它通过获取控件的属性值，作为参数值传递给数据值对象OrderInfo，从而利用页面上产生的订单信息创建订单对象，然后再调用领域对象Order的Inser()方法将OrderInfo对象插入到数据表中。此外，它还对领域对象ShoppingCart的数据项作出判断，如果其值等于0，就在页面中显示UI提示信息。此时，View的内容决定了Model的值，而Model值反过来又决定了View的显示内容。
6.3 ASP.NET控件
ASP.NET控件是View对象最重要的组成部分，它充分利用了面向对象的设计思想，通过封装与继承构建一个个控件对象，使得用户在开发Web页面时，能够重用这些控件，甚至自定义自己的控件。在第8章中，我已经介绍了.NET Framework中控件的设计思想，通过引入一种“复合方式”的Composite模式实现了控件树。在ASP.NET控件中，System.Web.UI.Control就是这棵控件树的根，它定义了所有ASP.NET控件共有的属性、方法和事件，并负责管理和控制控件的整个执行生命周期。
Control基类并没有包含UI的特定功能，如果需要提供与UI相关的方法属性，就需要从System.Web.UI.WebControls.WebControl类派生。该类实际上也是Control类的子类，但它附加了诸如ForeColor、BackColor、Font等属性。
除此之外，还有一个重要的类是System.Web.UI.UserControl，即用户控件类，它同样是Control类的子类。我们可以自定义一些用户控件派生自UserControl，在Visual Studio的Design环境下，我们可以通过拖动控件的方式将多种类型的控件组合成一个自定义用户控件，也可以在codebehind方式下，为自定义用户控件类添加新的属性和方法。
整个ASP.NET控件类的层次结构如图6-2所示：
图6-2 ASP.NET控件类的层次结构
ASP.NET控件的执行生命周期如表6-1所示：
| 阶段 |
控件需要执行的操作 |
要重写的方法或事件 |
| 初始化 |
初始化在传入 Web 请求生命周期内所需的设置。 |
Init 事件（OnInit 方法） |
| 加载视图状态 |
在此阶段结束时，就会自动填充控件的 ViewState 属性，控件可以重写 LoadViewState 方法的默认实现，以自定义状态还原。 |
LoadViewState 方法 |
| 处理回发数据 |
处理传入窗体数据，并相应地更新属性。 注意：只有处理回发数据的控件参与此阶段。 |
LoadPostData 方法（如果已实现 IPostBackDataHandler） |
| 加载 |
执行所有请求共有的操作，如设置数据库查询。此时，树中的服务器控件已创建并初始化、状态已还原并且窗体控件反映了客户端的数据。 |
Load 事件（OnLoad 方法） |
| 发送回发更改通知 |
引发更改事件以响应当前和以前回发之间的状态更改。 注意：只有引发回发更改事件的控件参与此阶段。 |
RaisePostDataChangedEvent 方法（如果已实现 IPostBackDataHandler） |
| 处理回发事件 |
处理引起回发的客户端事件，并在服务器上引发相应的事件。 注意：只有处理回发事件的控件参与此阶段。 |
RaisePostBackEvent 方法（如果已实现 IPostBackEventHandler） |
| 预呈现 |
在呈现输出之前执行任何更新。可以保存在预呈现阶段对控件状态所做的更改，而在呈现阶段所对的更改则会丢失。 |
PreRender 事件（OnPreRender 方法） |
| 保存状态 |
在此阶段后，自动将控件的 ViewState 属性保持到字符串对象中。此字符串对象被发送到客户端并作为隐藏变量发送回来。为了提高效率，控件可以重写 SaveViewState 方法以修改 ViewState 属性。 |
SaveViewState 方法 |
| 呈现 |
生成呈现给客户端的输出。 |
Render 方法 |
| 处置 |
执行销毁控件前的所有最终清理操作。在此阶段必须释放对昂贵资源的引用，如数据库链接。 |
Dispose 方法 |
| 卸载 |
执行销毁控件前的所有最终清理操作。控件作者通常在 Dispose 中执行清除，而不处理此事件。 |
UnLoad 事件（On UnLoad 方法） |
表6-1 ASP.NET控件的执行生命周期
在这里，控件设计利用了Template Method模式，Control基类提供了大部分protected虚方法，留待其子类改写其方法。以PetShop 4.0为例，就定义了两个ASP.NET控件，它们都属于System.Web.UI.WebControls.WebControl的子类。其中，CustomList控件派生自System.Web.UI.WebControls.DataList，CustomGrid控件则派生自System.Web.UI.WebControls.Repeater。
由于这两个控件都改变了其父类控件的呈现方式，故而，我们可以通过重写父类的Render虚方法，完成控件的自定义。例如CustomGrid控件：
public
class
CustomGrid : Repeater…
//
Static constants
protected
const
string
HTML1
=
"
cellspacing
=
0
><
tr
><
td colspan
=
2
>
"
;
protected
const
string
HTML2
=
"
protected
const
string
HTML3
=
"
protected
const
string
HTML4
=
"
private
static
readonly
Regex RX
=
new
Regex(
@"
^&page=/d+
"
, RegexOptions.Compiled);
private
const
string
LINK_PREV
=
"
private
const
string
LINK_MORE
=
"
private
const
string
KEY_PAGE
=
"
page
"
;
private
const
string
COMMA
=
"
?
"
;
private
const
string
AMP
=
"
&
"
;
override
protected
void
Render(HtmlTextWriter writer)
{ //Check there is some data attached if (ItemCount == 0) { writer.Write(emptyText); return; } //Mask the query string query = Context.Request.Url.Query.Replace(COMMA, AMP); query = RX.Replace(query, string.Empty); // Write out the first part of the control, the table header writer.Write(HTML1); // Call the inherited method base.Render(writer); // Write out a table row closure writer.Write(HTML2); //Determin whether next and previous buttons are required //Previous button? if (currentPageIndex > 0) writer.Write(string.Format(LINK_PREV, (currentPageIndex - 1) + query)); //Close the table data tag writer.Write(HTML3); //Next button? if (currentPageIndex < PageCount) writer.Write(string.Format(LINK_MORE, (currentPageIndex + 1) + query)); //Close the table writer.Write(HTML4); }
由于CustomGrid继承自Repeater控件，因而它同时还继承了Repeater的DataSource属性，这是一个虚属性，它默认的set访问器属性如下：
public
virtual
object
DataSource
{ get {… } set { if (((value != null) && !(value is IListSource)) && !(value is IEnumerable)) { throw new ArgumentException(SR.GetString("Invalid_DataSource_Type", new object[] { this.ID })); } this.dataSource = value; this.OnDataPropertyChanged(); }}
对于CustomGrid而言，DataSource属性有着不同的设置行为，因而在定义CustomGrid控件的时候，需要改写DataSource虚属性，如下所示：
private
IList dataSource;
private
int
itemCount;
override
public
object
DataSource
{ set { //This try catch block is to avoid issues with the VS.NET designer //The designer will try and bind a datasource which does not derive from ILIST try { dataSource = (IList)value; ItemCount = dataSource.Count; } catch { dataSource = null; ItemCount = 0; } }}
当设置的value对象值不为IList类型时，set访问器就将捕获异常，然后将dataSource字段设置为null。
由于我们改写了DataSource属性，因而改写Repeater类的OnDataBinding()方法也就势在必行。此外，CustomGrid还提供了分页的功能，我们也需要实现分页的相关操作。与DataSource属性不同，Repeater类的OnDataBinding()方法实际上是继承和改写了Control基类的OnDataBinding()虚方法，而我们又在此基础上改写了Repeater类的OnDataBinding()方法：
override
protected
void
OnDataBinding(EventArgs e)
{ //Work out which items we want to render to the page int start = CurrentPageIndex * pageSize; int size = Math.Min(pageSize, ItemCount - start); IList page = new ArrayList(); //Add the relevant items from the datasource for (int i = 0; i < size; i++) page.Add(dataSource[start + i]); //set the base objects datasource base.DataSource = page; base.OnDataBinding(e);}
此外，CustomGrid控件类还增加了许多属于自己的属性和方法，例如PageSize、PageCount属性以及SetPage()方法等。正是因为ASP.NET控件引入了Composite模式与Template Method模式，当我们在自定义控件时，就可以通过继承与改写的方式来完成控件的设计。自定义ASP.NET控件一方面可以根据系统的需求实现特定的功能，也能够最大限度地实现对象的重用，既可以减少编码量，同时也有利于未来对程序的扩展与修改。
在PetShop 4.0中，除了自定义了上述WebControl控件的子控件外，最主要的还是利用了用户控件。在Controls文件夹下，一共定义了11个用户控件，内容涵盖客户地址信息、信用卡信息、购物车信息、期望列表（Wish List）信息以及导航信息、搜索结果信息等。它们相当于是一些组合控件，除了包含了子控件的方法和属性外，也定义了一些必要的UI实现逻辑。以ShoppingCartControl用户控件为例，它会在该控件被呈现（Render）之前，做一些数据准备工作，获取购物车数据，并作为数据源绑定到其下的Repeater控件：
public
partial
class
ShoppingCartControl : System.Web.UI.UserControl
protected
void
Page_PreRender(
object
sender, EventArgs e)
{ if (!IsPostBack) { BindCart(); } }
private
void
BindCart()
{ ICollection<CartItemInfo> cart = Profile.ShoppingCart.CartItems; if (cart.Count > 0) { repShoppingCart.DataSource = cart; repShoppingCart.DataBind(); PrintTotal(); plhTotal.Visible = true; } else { repShoppingCart.Visible = false; plhTotal.Visible = false; lblMsg.Text = "Your cart is empty."; } }
在ShoppingCart页面下，我们可以加入该用户控件，如下所示：
<
PetShopControl:shoppingcartcontrol id
=
"
ShoppingCartControl1
"
runat
=
"
server
"
>
PetShopControl:shoppingcartcontrol
>
由于ShoppingCartControl用户控件已经实现了用于呈现购物车数据的逻辑，那么在ShoppingCart.aspx.cs中，就可以不用负责这些逻辑，在充分完成对象重用的过程中，同时又达到了职责分离的目的。用户控件的设计者与页面设计者可以互不干扰，分头完成自己的设计。特别是对于页面设计者而言，他可以是单一的UI设计人员角色，仅需要关注用户界面是否美观与友好，对于表示层中对领域对象的调用与操作就可以不必理会，整个页面的代码也显得结构清晰、逻辑清楚，无疑也“干净”了不少。
petshop4.0 详解之七(PetShop表示层设计)6.4 ASP.NET 2.0新特性
由于PetShop 4.0是基于.NET Framework 2.0平台开发的电子商务系统，因而它在表示层也引入了许多ASP.NET 2.0的新特性，例如MemberShip、Profile、Master Page、登录控件等特性。接下来，我将结合PetShop 4.0的设计分别介绍它们的实现。
6.4.1 Profile特性
Profile提供的功能是针对用户的个性化服务。在ASP.NET 1.x版本时，我们可以利用Session、Cookie等方法来存储用户的状态信息。然而Session对象是具有生存期的，一旦生存期结束，该对象保留的值就会失效。Cookie将用户信息保存在客户端，它具有一定的安全隐患，一些重要的信息不能存储在Cookie中。一旦客户端禁止使用Cookie，则该功能就将失去应用的作用。
Profile的出现解决了如上的烦恼，它可以将用户的个人化信息保存在指定的数据库中。ASP.NET 2.0的Profile功能默认支持Access数据库和SQL Server数据库，如果需要支持其他数据库，可以编写相关的ProfileProvider类。Profile对象是强类型的，我们可以为用户信息建立属性，以PetShop 4.0为例，它建立了ShoppingCart、WishList和AccountInfo属性。
由于Profile功能需要访问数据库，因而在数据访问层（DAL）定义了和Product等数据表相似的模块结构。首先定义了一个IProfileDAL接口模块，包含了接口IPetShopProfileProvider：
public
interface
IPetShopProfileProvider
{ AddressInfo GetAccountInfo(string userName, string appName); void SetAccountInfo(int uniqueID, AddressInfo addressInfo); IList<CartItemInfo> GetCartItems(string userName, string appName, bool isShoppingCart); void SetCartItems(int uniqueID, ICollection<CartItemInfo> cartItems, bool isShoppingCart); void UpdateActivityDates(string userName, bool activityOnly, string appName); int GetUniqueID(string userName, bool isAuthenticated, bool ignoreAuthenticationType, string appName); int CreateProfileForUser(string userName, bool isAuthenticated, string appName); IList<string> GetInactiveProfiles(int authenticationOption, DateTime userInactiveSinceDate, string appName); bool DeleteProfile(string userName, string appName); IList<CustomProfileInfo> GetProfileInfo(int authenticationOption, string usernameToMatch, DateTime userInactiveSinceDate, string appName, out int totalRecords);}
因为PetShop 4.0版本分别支持SQL Server和Oracle数据库，因而它分别定义了两个不同的PetShopProfileProvider类，实现IPetShopProfileProvider接口，并放在两个不同的模块SQLProfileDAL和OracleProfileDAL中。具体的实现请参见PetShop 4.0的源代码。
同样的，PetShop 4.0为Profile引入了工厂模式，定义了模块ProfileDALFActory，工厂类DataAccess的定义如下：
public
sealed
class
DataAccess
{ private static readonly string profilePath = ConfigurationManager.AppSettings["ProfileDAL"]; public static PetShop.IProfileDAL.IPetShopProfileProvider CreatePetShopProfileProvider() { string className = profilePath + ".PetShopProfileProvider"; return (PetShop.IProfileDAL.IPetShopProfileProvider)Assembly.Load(profilePath).CreateInstance(className); }}
在业务逻辑层（BLL）中，单独定义了模块Profile，它添加了对BLL、IProfileDAL和ProfileDALFactory模块的程序集。在该模块中，定义了密封类PetShopProfileProvider，它继承自System.Web.Profile.ProfileProvider类，该类作为Profile的Provider基类，用于在自定义配置文件中实现相关的配置文件服务。在PetShopProfileProvider类中，重写了父类ProfileProvider中的一些方法，例如Initialize()、GetPropertyValues()、SetPropertyValues()、DeleteProfiles()等方法。此外，还为ShoppingCart、WishList、AccountInfo属性提供了Get和Set方法。至于Provider的具体实现，则调用工厂类DataAccess创建的具体类型对象，如下所示：
private static readonly IPetShopProfileProvider dal = DataAccess.CreatePetShopProfileProvider();
定义了PetShop.Profile.PetShopProfileProvider类后，才可以在web.config配置文件中配置如下的配置节：
<
profile automaticSaveEnabled
=
"
false
"
defaultProvider
=
"
ShoppingCartProvider
"
>
<
providers
>
<
add name
=
"
ShoppingCartProvider
"
connectionStringName
=
"
SQLProfileConnString
"
type
=
"
PetShop.Profile.PetShopProfileProvider
"
applicationName
=
"
.NET Pet Shop 4.0
"
/>
<
add name
=
"
WishListProvider
"
connectionStringName
=
"
SQLProfileConnString
"
type
=
"
PetShop.Profile.PetShopProfileProvider
"
applicationName
=
"
.NET Pet Shop 4.0
"
/>
<
add name
=
"
AccountInfoProvider
"
connectionStringName
=
"
SQLProfileConnString
"
type
=
"
PetShop.Profile.PetShopProfileProvider
"
applicationName
=
"
.NET Pet Shop 4.0
"
/>
providers
>
<
properties
>
<
add name
=
"
ShoppingCart
"
type
=
"
PetShop.BLL.Cart
"
allowAnonymous
=
"
true
"
provider
=
"
ShoppingCartProvider
"
/>
<
add name
=
"
WishList
"
type
=
"
PetShop.BLL.Cart
"
allowAnonymous
=
"
true
"
provider
=
"
WishListProvider
"
/>
<
add name
=
"
AccountInfo
"
type
=
"
PetShop.Model.AddressInfo
"
allowAnonymous
=
"
false
"
provider
=
"
AccountInfoProvider
"
/>
properties
>
profile
>
在配置文件中，针对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属性：
public
partial
class
ShoppingCart : System.Web.UI.Page
{ protected void Page_PreInit(object sender, EventArgs e) { if (!IsPostBack) { string itemId = Request.QueryString["addItem"]; if (!string.IsNullOrEmpty(itemId)) { Profile.ShoppingCart.Add(itemId); Profile.Save(); // Redirect to prevent duplictations in the cart if user hits "Refresh" Response.Redirect("~/ShoppingCart.aspx", true); } } }}
在上述的代码中，Profile属性的值从何而来？实际上，在我们为web.config配置文件中对Profile进行配置后，启动Web应用程序，ASP.NET会根据该配置文件中的相关配置创建一个ProfileCommon类的实例。该类继承自System.Web.Profile.ProfileBase类。然后调用从父类继承来的GetPropertyValue和SetPropertyValue方法，检索和设置配置文件的属性值。然后，ASP.NET将创建好的ProfileCommon实例设置为页面的Profile属性值。因而，我们可以通过智能感知获取Profile的ShoppingCart属性，同时也可以利用ProfileCommon继承自ProfileBase类的Save()方法，根据属性值更新Profile的数据源。
6.4.2 Membership特性
PetShop 4.0并没有利用Membership的高级功能，而是直接让Membership特性和ASP.NET 2.0新增的登录控件进行绑定。由于.NET Framework 2.0已经定义了针对SQL Server的SqlMembershipProvider，因此对于PetShop 4.0而言，实现Membership比之实现Profile要简单，仅仅需要为Oracle数据库定义MembershipProvider即可。在PetShop.Membership模块中，定义了OracleMembershipProvider类，它继承自System.Web.Security.MembershipProvider抽象类。
OracleMembershipProvider类的实现具有极高的参考价值，如果我们需要定义自己的MembershipProvider类，可以参考该类的实现。
事实上OracleMemberShip类的实现并不复杂，在该类中，主要是针对用户及用户安全而实现相关的行为。由于在父类MembershipProvider中，已经定义了相关操作的虚方法，因此我们需要作的是重写这些虚方法。由于与Membership有关的信息都是存储在数据库中，因而OracleMembershipProvider与SqlMembershipProvider类的主要区别还是在于对数据库的访问。对于SQL Server而言，我们利用aspnet_regsql工具为Membership建立了相关的数据表以及存储过程。也许是因为知识产权的原因，Microsoft并没有为Oracle数据库提供类似的工具，因而需要我们自己去创建membership的数据表。此外，由于没有创建Oracle数据库的存储过程，因而OracleMembershipProvider类中的实现是直接调用SQL语句。以CreateUser()方法为例，剔除那些繁杂的参数判断与安全性判断，SqlMembershipProvider类的实现如下：
public
override
MembershipUser CreateUser(
string
username,
string
password,
string
email,
string
passwordQuestion,
string
passwordAnswer,
bool
isApproved,
object
providerUserKey,
out
MembershipCreateStatus status)
{ MembershipUser user1; //前面的代码略; try { SqlConnectionHolder holder1 = null; try { holder1 = SqlConnectionHelper.GetConnection(this._sqlConnectionString, true); this.CheckSchemaVersion(holder1.Connection); DateTime time1 = this.RoundToSeconds(DateTime.UtcNow); SqlCommand command1 = new SqlCommand("dbo.aspnet_Membership_CreateUser", holder1.Connection); command1.CommandTimeout = this.CommandTimeout; command1.CommandType = CommandType.StoredProcedure; command1.Parameters.Add(this.CreateInputParam("@ApplicationName", SqlDbType.NVarChar, this.ApplicationName)); command1.Parameters.Add(this.CreateInputParam("@UserName", SqlDbType.NVarChar, username)); command1.Parameters.Add(this.CreateInputParam("@Password", SqlDbType.NVarChar, text2)); command1.Parameters.Add(this.CreateInputParam("@PasswordSalt", SqlDbType.NVarChar, text1)); command1.Parameters.Add(this.CreateInputParam("@Email", SqlDbType.NVarChar, email)); command1.Parameters.Add(this.CreateInputParam("@PasswordQuestion", SqlDbType.NVarChar, passwordQuestion)); command1.Parameters.Add(this.CreateInputParam("@PasswordAnswer", SqlDbType.NVarChar, text3)); command1.Parameters.Add(this.CreateInputParam("@IsApproved", SqlDbType.Bit, isApproved)); command1.Parameters.Add(this.CreateInputParam("@UniqueEmail", SqlDbType.Int, this.RequiresUniqueEmail ? 1 : 0)); command1.Parameters.Add(this.CreateInputParam("@PasswordFormat", SqlDbType.Int, (int) this.PasswordFormat)); command1.Parameters.Add(this.CreateInputParam("@CurrentTimeUtc", SqlDbType.DateTime, time1)); SqlParameter parameter1 = this.CreateInputParam("@UserId", SqlDbType.UniqueIdentifier, providerUserKey); parameter1.Direction = ParameterDirection.InputOutput; command1.Parameters.Add(parameter1); parameter1 = new SqlParameter("@ReturnValue", SqlDbType.Int); parameter1.Direction = ParameterDirection.ReturnValue; command1.Parameters.Add(parameter1); command1.ExecuteNonQuery(); int num3 = (parameter1.Value != null) ? ((int) parameter1.Value) : -1; if ((num3 < 0) || (num3 > 11)) { num3 = 11; } status = (MembershipCreateStatus) num3; if (num3 != 0) { return null; } providerUserKey = new Guid(command1.Parameters["@UserId"].Value.ToString()); time1 = time1.ToLocalTime(); user1 = new MembershipUser(this.Name, username, providerUserKey, email, passwordQuestion, null, isApproved, false, time1, time1, time1, time1, new DateTime(0x6da, 1, 1)); } finally { if (holder1 != null) { holder1.Close(); holder1 = null; } } } catch { throw; } return user1;}
代码中，aspnet_Membership_CreateUser为aspnet_regsql工具为membership创建的存储过程，它的功能就是创建一个用户。
OracleMembershipProvider类中对CreateUser()方法的定义如下：
public
override
MembershipUser CreateUser(
string
username,
string
password,
string
email,
string
passwordQuestion,
string
passwordAnswer,
bool
isApproved,
object
userId,
out
MembershipCreateStatus status)
{ //前面的代码略; //Create connection OracleConnection connection = new OracleConnection(OracleHelper.ConnectionStringMembership); connection.Open(); OracleTransaction transaction = connection.BeginTransaction(IsolationLevel.ReadCommitted); try { DateTime dt = DateTime.Now; bool isUserNew = true; // Step 1: Check if the user exists in the Users table: create if not int uid = GetUserID(transaction, applicationId, username, true, false, dt, out isUserNew); if(uid == 0) { // User not created successfully! status = MembershipCreateStatus.ProviderError; return null; } // Step 2: Check if the user exists in the Membership table: Error if yes. if(IsUserInMembership(transaction, uid)) { status = MembershipCreateStatus.DuplicateUserName; return null; } // Step 3: Check if Email is duplicate if(IsEmailInMembership(transaction, email, applicationId)) { status = MembershipCreateStatus.DuplicateEmail; return null; } // Step 4: Create user in Membership table int pFormat = (int)passwordFormat; if(!InsertUser(transaction, uid, email, pass, pFormat, salt, "", "", isApproved, dt)) { status = MembershipCreateStatus.ProviderError; return null; } // Step 5: Update activity date if user is not new if(!isUserNew) { if(!UpdateLastActivityDate(transaction, uid, dt)) { status = MembershipCreateStatus.ProviderError; return null; } } status = MembershipCreateStatus.Success; return new MembershipUser(this.Name, username, uid, email, passwordQuestion, null, isApproved, false, dt, dt, dt, dt, DateTime.MinValue); } catch(Exception) { if(status == MembershipCreateStatus.Success) status = MembershipCreateStatus.ProviderError; throw; } finally { if(status == MembershipCreateStatus.Success) transaction.Commit(); else transaction.Rollback(); connection.Close(); connection.Dispose(); }}
