反射是.net的核心功能，十分的强大。但是好像微软封装的太过了，作为程序员，在实际项目中我很少用到反射（估计是参加的大型项目太少了，需要交互第三方的项目太少了）。
工厂模式是软件设计模式中重要的一种，在面向接口编程中，怎么把接口与实现接口的类进行关联而不是在程序中直接使用
SupportLaw.Dal.Dic_Table dal = new SupportLaw.Dal.Dic_Table();
这样违反了 具体不能依赖具体的（依赖倒置原则） 设计模式。通俗来点讲 这样直接做有主要两点的缺点：
1：dal里面会有大量的操作数据库代码。（东软生成也有很多哦）。每次new dal，其实我们只需要其中的一个（一类型）或者几个方法（这个就是接口哦）。都在实例化不是很浪费。
根据里氏替换原则，这里使用接口来实例化的类型（所以接口的设计部是东软生成啊！！我的设计一般是 添加修改删除 作为一个接口。查询（各种各样的查询） 作为另一个接口）。
SupportLaw.IDal.IDic_Table dal = new SupportLaw.Dal.Dic_Table();
2： 项目的可维护性。（公司真实的例子：公司一个项目面临演示，除了问题。这个项目从数据提取，数据处理，数据展示 三个人做的。。然后一个人加班另两个一起加班。苦逼！当然里面有各种各样的原因。其中最重要的原因就是 相互 依赖，没有统一的规则（接口））。为了项目的可维护性，为了以后需求变动的时候（软件项目经常的事情）。
好了。使用接口解决了上面的两个问题了，但是把实例化语句放在bll层处理也是不好的吧。因为你如果那样做了，你的bll层是必须引用 DAL IDal层。比不做改动之前你的项目引用的还要多一个IDal。这个时候我们需要一个中间层来处理接口与实现类的关联。因为具有统一的特性（这里用词不好，但是不知道用啥了）--给一个接口，返回一个接口实现类。所以这里用到了工厂。
传入的参数 泛型 T。具体代码如下：
public static T Creat<T>()
{
string str = typeof(T).Name; //获取类型名称
Assembly assembly = Assembly.Load("SupportLaw.Dal"); //加实现类载程序集
Type[] types = assembly.GetTypes(); //获取所有类型
foreach (var t in types)
{
if (t.GetInterface(str) != null) //如果存在实现类继承了接口T，则返回实现T类，否则返回 default(T)
{
var userBll = (T)Activator.CreateInstance(t);
return userBll;
}
}
return default(T);
}