PetShop数据库解读

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

PetShop的工厂模式

PetShop之业务逻辑层设计

PetShop数据库解读

PetShop 4.0使用了四个数据库，分别为：MSPetShop4 、MSPetShop4Orders 、MSPetShop4Profile 、MSPetShop4Services　　

一、MSPetShop4

其中MSPetShop4用来管理产品、分类等基本数据信息，其中共有六个表
　　AspNet_SqlCacheTablesForChangeNotification
　　Category
　　Inventory
　　Item

Category表产品分类表。这个分类主要对产品在大类别上进行分类，比如在petshop中，有鱼类，鸟类等。里面的字段的意思我想大家看得很明白，一个是分类ID，一个是类别名称，一个是他的描述，主键是分类ID。

product表是产品表，这个产品并不是最终的产品，而是一个抽象意义上的产品，比如说鱼，有很多种类的鱼，比如鲨鱼等等，对于一个宠物商店，鲨鱼这个种类有好几个不同和名字的，那么摆在货架上的就是好几个不同的名字的。具体的每个名字的就要用item表来表示了。那么在product这张表中，他的字段是：产品ID，产品分类，产品名字，备注描述，此类产品对应的图片地址。在这张表中，以产品ID为主键，同时建立了四个索引：1.产品名称；2.分类ID；3.产品名称＋分类ID；4.产品ID＋产品名称＋分类ID。有关索引的相关知识，请查阅数据库方面的资料。

item表是具体的宠物。每一种产品（product）都对应有一种或几种具体的item。在这张表中productID为其对应的产品，并在这个字段上建立外键约束。这个表的字段从上到下的意思分别为：宠物项ID，对应产品ID，宠物价格，unitCost是什么意思我还没搞清楚，供应商ID，状态（我只看到里面的数据为P，但不知道怎么样修改），宠物名字，宠物所对应的图片地址。在这张表里面，itemID为主键，productid、supplier为外键，也就是他们的值是product表和supplier表中的值，建立了一个大的索引：itemid+productID+ListPrice+Name。

supplier表是供应商表。这张表的作用，我还没看到有多大，只是在这里标识每一种宠物的供应者是谁，在标准的petshop安装后，里面只有两条数据，那么现在我来介绍一下这张表里面的字段的意思。上图中标识主键的为供应商ID，以下分别为供应商名字，status里面的值为AC，我搞不太清楚代表什么意思，Addr1,Addr2想必大家一看就明白是什么意思了，city从字面意思也可以搞清楚，state是代表美国的哪一个州，zip为邮政编码，后面的是电话号码。

Inventory是宠物的库存表。ItemID为宠物的ID，下面为库存的数目。我个人认为这里的ItemID应该做一个外键约束，但是petshop并没有做，我不知道这是什么原因。

根据上面的数据库表，petshop抽象出几个数据实体类。让我们先来分析一下，上面的数据库中，一共有六张表，可以表示这么几个概念，分别是缓存，类别，产品（我不知道这么叫好不好），宠物信息，供应商，库存。可以做为数据实体的肯定要去除缓存，库存，因为缓存只是一个技术，库存则是宠物信息里面可以包含的一个属性，我认为，余下的都可以抽象或是说映射。但是petshop中只对类别，产品，宠物信息进行了抽象实体，没有供应商的具体类，究其原因，可能是因为在petshop中，供应商并不是一个主要的矛盾，也就是说宠物商店和供应商没有太大关系，所以没有包含。那么就让我们看一看在程序中是怎么样来抽象的。如下图所示：

除AspNet_SqlCacheTablesForChangeNotification是为了配合.net的缓存处理外，其它表都是基本数据表，它们在PetShop 4.0中有对应的模型。　　

二、MSPetShop4Orders

分别主要用来存储订单明细、订单基本信息和订单状态的数据。

LineItem 存储定单中购买商品的信息，例如：定单号，商品ID，单价，数量

Orders 用于存储商品定单详细信息，例如：定单号，用户ID，联系信息等

OrderStatus 用于记录定单状态

三、MSPetShop4Profile

MSPetShop4Profile 数据库说明

主要存储账户基本信息、购物车信息和用户配置信息。

Account 记录客户基本信息，例如：姓名，电子邮件地址，住址等。

Cart  存储购物车和意象清单中的商品信息。

Profiles 用于存储客户活动基本信息例如：用户名，是否匿名访问，上次登陆时间等

四、MSPetShop4Services

MSPetShop4Services 数据库说明

存储成员资格，角色，用户配置，和应用程序等信息。

aspnet_Applications 存储数据库所涉及应用程序有关信息。

aspnet_Membership 存储与用户相关信息例如：用户登陆密码，创建时间。

aspnet_Paths 存储应用程序和目录路径的对应关系数据。

aspnet_PersonalizationAllUsers 存储针对所有用户的Web部件个性化设置信息。

aspnet_PersonalizationPerUser 存储针对每个特定用户的Web部件个性化设置信息。

aspnet_Profile 存储用户配置数据。

aspnet_Roles 存储角色信息。

aspnet_SchemaVersions 存储用户配置信息支持的模式。

aspnet_Users 记录用户基本信息。

aspnet_UsersInRoles 存储用户和角色的关系数据。

aspnet_WebEvent_Events 存储Web事件相关信息。

通过将一个完整系统的数据按功能进行划分，各部分数据存储到独立的数据库服务器中，便是一种典型的分布式数据库模式。采用这种方式，不仅可以提高数据库以及应用的复用性，而且可以分散数据库服务器的压力，从而在某种程序上解决数据库瓶颈。

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的工厂模式

第一部份：工厂模式

一、项目名称及描述：(实现步骤为：4-3-6-5-2-1)

1、WEB＝表示层

2、BLL＝业务逻辑层

3、IDAL＝数据访问层接口定义

4、Model＝业务实体

5、DALFactory＝数据层的抽象工厂(创建反射)

6、SQLServerDAL＝SQLServer数据访问层 / OracleDAL＝Oracle数据访问层

DBUtility 数据库访问组件基础类

二、项目引用关系

1、Web 引用 BLL。

2、BLL 引用 IDAL，Model，使用DALFactory创建实例。

3、IDAL 引用 Model。

4、Model 无引用。

5、DALFactory 引用IDAL，通过读取web.config里设置的程序集，加载类的实例，返回给BLL使用。

6、SQLServerDAL 引用 Model和IDAL，被DALFactory加载的程序集，实现接口里的方法。

三、实现步骤

1、创建Model，实现业务实体。

2、创建IDAL，实现接口。

3、创建SQLServerDAL，实现接口里的方法。

4、增加web.config里的配置信息，为SQLServerDAL的程序集。

5、创建DALFactory，返回程序集的指定类的实例。

6、创建BLL，调用DALFactory，得到程序集指定类的实例，完成数据操作方法。

7、创建WEB，调用BLL里的数据操作方法。

注意：

1、web.config里的程序集名称必须与SQLServerDAL里的输出程序集名称一致。

2、DALFactory里只需要一个DataAccess类，可以完成创建所有的程序集实例。

3、项目创建后，注意修改各项目的默认命名空间和程序集名称。

4、注意修改解决方案里的项目依赖。

5、注意在解决方案里增加各项目引用。

第二部份：Profile的使用(也是工厂方法)

概述：PetShop的Profile通过自己的ProfileProvider来实现。

一、项目名称及描述

1、Profile＝Profile的数据访问层

2、ProfileDALFactory＝ProfileDAL的工厂类(反射创建ProfileDAL)

3、IProfileDAL＝Profile的数据访问层接口定义

4、SQLProfileDAL＝SQL Server 的Profile Providers 做用户状态管理

二、项目引用关系

1、Profile 引用 ProfileDALFactory，IProfileDAL，Model。通过ProfileDALFactory的方法创建程序集实例。

2、ProfileDALFactory 引用 IProfileDAL。实现程序集实例的方法。
3、IProfileDAL 引用 Model。实现接口。
4、SQLProfileDAL 引用 Model，IProfileDAL。被ProfileDALFactory加载的程序集，实现接口里的方法。

三、实现步骤

1、创建Model，实现业务实体。

2、创建IProfileDAL，实现接口。

3、创建SQLProfileDAL，实现接口里的方法。

4、增加web.config里的配置信息，为SQLProfileDAL的程序集。

5、创建ProfileDALFactory，返回程序集的指定类的实例。

6、创建Profile，实现Profile Provider。

7、在web.config文件中增加配置节profile，增加属性及类型，provider为Profile。

例：
<system.web>
     <profileautomaticSaveEnabled="false" defaultProvider="默认的Profile Provider">
          <providers>
               <addname="自己命名的Provider名称" connectionStringName="配置文件里的数据库链接名称" type="自己的Provider实现类，需要自己重写" applicationName="自己定义的应用程序名称"/>
          </providers>
          <properties>
               <addname="自己命名的Profile名称" type="自己的类，需要构建" allowAnonymous="false" provider="上面的自己命名的Provider名称"/>
          </properties>
     </profile>
</system.web>

注意事项：

1、Profile的type可以为自己的类，包括业务实例或方法等。

2、通过重写ProfileProvider里的部份方法，实现在自己的数据库里记录自己想要的个性化用户信息。

3、如果每个用户有大量的数据信息，则该类数据信息不要通过Profile来记录。

4、被定义为Profile的type的类，必须在类定义前增加[Serializable]以实现可序列化。

5、接口定义的类型必须为类。

6、Profile Provider类里必须增加System.Web.Profile和System.Configuration的引用到项目中。

7、如果需要支持匿名用户，增加<anonymousIdentification enabled="true" />到web.config里，在profile之间。

8、使用Profile.Save方法后，将调用ProfileDALFactory里的方法将数据保存到数据库。

PetShop之业务逻辑层设计

五 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的依赖关系。这种设计对于业务逻辑相对比较复杂的系统而言，更符合面向对象的设计思想，有利于我们建立可抽取、可替换的“抽屉”式三层架构。