petshop中的反射工厂模式

Petshop里的return (PetShop.IDAL.IAccount) Assembly.Load(path).CreateInstance(className);到底表示什么意思呢？返回一个接口类型有什么用呢？

IAccount dal = PetShop.DALFactory.Account.Create();
调用了 IAccount.CS

public class Account
{
public static PetShop.IDAL.IAccount Create()
{
/// Look up the DAL implementation we should be using
string path = System.Configuration.ConfigurationSettings.AppSettings["WebDAL"];
string className = path + ".Account";

// Using the evidence given in the config file load the appropriate assembly and class
return (PetShop.IDAL.IAccount) Assembly.Load(path).CreateInstance(className);
}
}

 

Create()方法返回IAccount接口，用System.Configuration.ConfigurationSettings.AppSettings["WebDAL"];则可以得到Web.config的<appsettings>节点中的关于系统中应该使用哪个数据访问层（SqlserverDAL还是OracleDAL）的信息。因为我在安装PetShop3.0时选择的是Sqlserver所以在此是：value="PetShop.SQLServerDAL"，如果用的是Oracle那就是value="PetShop.OracleDAL" 了吧！而且这个文件也应该是可以更改的。接下来className=path+”.Account”返回的应该是PetShop.SQLServerDAL.Account,然后再用Assembly.Load加载PetShop.SQLServerDAL.dll，同时创建PetShop.SQLServerDAL.Account的实例，并以接口（PetShop.IDAL.IAccount）类型返回。这样BLL调用IAccount接口时就会用PetShop.SQLServerDAL.Account类的实现代码。（回上面第4再看一下）

 

看！这样根据系统当前Web.config文件的配置描述（这也应该是系统运行时实际的配置），BLL层只要像下面这样：

// Get an instance of the account DAL using the DALFactory

              IAccount dal = PetShop.DALFactory.Account.Create();

AccountInfo account = dal.SignIn(userId, password);//<<ß----看看上面第4点的IAccount接口

就可以直接调用接口方法通过下层DAL层操作数据库了（在此具体为用户账号相关操作），而BLL层并不用知道应该通过SqlserverDAL还是OracleDAL访问数据库，这由都DAL Factory决定，你用的是什么数据库以及底层细节，更不用BLL知道，这样做的好处是对于BLL层以及更上层的程序不会或很少机率会因为底层程序变动影响，因为BLL层中调用接口就行了，只要那个接口定义没变，一切仍然OK.

 

Create()方法返回IAccount接口，用System.Configuration.ConfigurationSettings.AppSettings["WebDAL"];则可以得到Web.config的<appsettings>节点中的关于系统中应该使用哪个数据访问层（SqlserverDAL还是OracleDAL）的信息。因为我在安装PetShop3.0时选择的是Sqlserver所以在此是：value="PetShop.SQLServerDAL"，如果用的是Oracle那就是value="PetShop.OracleDAL" 了吧！而且这个文件也应该是可以更改的。接下来className=path+”.Account”返回的应该是PetShop.SQLServerDAL.Account,然后再用Assembly.Load加载PetShop.SQLServerDAL.dll，同时创建PetShop.SQLServerDAL.Account的实例，并以接口（PetShop.IDAL.IAccount）类型返回。这样BLL调用IAccount接口时就会用PetShop.SQLServerDAL.Account类的实现代码。（回上面第4再看一下）

 

看！这样根据系统当前Web.config文件的配置描述（这也应该是系统运行时实际的配置），BLL层只要像下面这样：

// Get an instance of the account DAL using the DALFactory

              IAccount dal = PetShop.DALFactory.Account.Create();

AccountInfo account = dal.SignIn(userId, password);//<<ß----看看上面第4点的IAccount接口

就可以直接调用接口方法通过下层DAL层操作数据库了（在此具体为用户账号相关操作），而BLL层并不用知道应该通过SqlserverDAL还是OracleDAL访问数据库，这由都DAL Factory决定，你用的是什么数据库以及底层细节，更不用BLL知道，这样做的好处是对于BLL层以及更上层的程序不会或很少机率会因为底层程序变动影响，因为BLL层中调用接口就行了，只要那个接口定义没变，一切仍然OK.

Petshorp这么做是为了实现商业逻辑层能跨数据库复用（反射工厂模式）
利用ADO.net的框架很容易解决数据库访问的统一外观问题，但是具体每个业务查询的Sql语句仍然带有数据库特性。所以Petshorp有一个DAL(Data Access Layer)数据访问层专门写数据库查询语句并做具体和数据库特性有关的数据处理供商业逻辑层使用，既然商业逻辑层不关心这些Sql实现，当然要定义统一的接口IDAL。
你引用的这部分其实是利用工厂模式达到商业逻辑层封装好后不再重新编译就能针对不同数据库复用的效果，可以假想如果DAL不动态Load的话，Load谁都写在代码里，那肯定要重新编译。
Petshorp的思想不错，不过实际编程代价很大，毕竟sql的很多共性可以利用。
msdn的developer center找最新“Enterprise Library Data Access Application Block”看看，感觉这个框架会更出色