PETSHOP4.0学习札记一 反射

还是回到对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值统一管理起来，这有利于各种动态创建对象的管理和未来的维护。

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/nuaalfm/archive/2007/09/18/1788910.aspx