Ioc模式和MEF

IOC模式

　　Ioc模式(又称DI：Dependency Injection 依赖注射).

　　分离关注（ Separation of Concerns : SOC）是Ioc模式和AOP产生最原始动力，通过功能分解可得到关注点，这些关注可以是 组件Components, 方面Aspects或服务Services。

　　从GoF设计模式中，我们已经习惯一种思维编程方式：Interface Driven Design 接口驱动，接口驱动有很多好处，可以提供不同灵活的子类实现，增加代码稳定和健壮性等等，但是接口一定是需要实现的，也就是如下语句迟早要执行：

AInterface a = new AInterfaceImp();

AInterfaceImp是接口AInterface的一个子类，Ioc模式可以延缓接口的实现，根据需要实现，有个比喻：接口如同空的模型套，在必要时，需要向模型套注射石膏，这样才能成为一个模型实体，因此，我们将人为控制接口的实现成为“注射”。

　　Ioc英文为 Inversion of Control，即反转模式，这里有著名的好莱坞理论：你呆着别动，到时我会找你。后被Martin Fowler改名为 Dependency Injection 依赖注射，也就是将类之间的关系通过第三方进行注射，不需要类自己去解决调用关系。

　　其实Ioc模式也是解决调用者和被调用者之间的一种关系，上述AInterface实现语句表明当前是在调用被调用者AInterfaceImp，由于被调用者名称写入了调用者的代码中，这产生了一个接口实现的原罪：彼此联系，调用者和被调用者有紧密联系，在UML中是用依赖 Dependency 表示。

　  但是这种依赖在分离关注的思维下是不可忍耐的，必须切割，实现调用者和被调用者解耦，新的Ioc模式 Dependency Injection 模式由此产生了， Dependency Injection模式是依赖注射的意思，也就是将依赖先剥离，然后在适当时候再注射进入。

IOC模式大致有三种：

第一种：接口注入的方式

第二种：构造函数注入的方式

第三种：属性注入的方式

选择MEF方式

.net中可用的IOC容器非常多，如 CastleWindsor，Unity，Autofac，ObjectBuilder，StructureMap，Spring.Net等，这些第三方工具各不相同，但功能大体都相同，大都需要事先对接口与实现进行配对（通过代码或配置文件），然后由系统自动或手动来通过接口来获得相应实现类的实例，对象实例化的工作由IOC容器自动完成。

　　MEF相对于上面的这些IOC容器有什么优势呢？下面是我推荐的理由：

1..net4.0 自带：MEF的功能在 System.ComponentModel.Composition.dll 程序集中，直接引用即可使用，不用安装第三方组件 2.0 配置：MEF是不需要使用配置文件或代码对接口与实现进行一一配对的，只需要简单的使用几个Attribute特性，就能自动完成源与目标的配对工作 3.自动化：系统初始化时自动遍历程序目录或指定文件夹下的dll，根据程序集中接口与类的特定Attribute特性进行自动配对。