关于依赖倒置(DIP)
高层模块不依赖于低层模块的实现，而低层模块依赖于高层模块定义的接口,通俗的讲，就是高层模块定义接口，低层模块负责实现，这在我们实际开发中经常被用到，层与层之间引用，经常被添加一个接口层去隔离，在接口层定义相关业务规范，而底层去实现它，高层只引用这个接口，当高级需要其它扩展，直接添加新的接口，由新的底层模块去实现即可，底层其它代码不需要修改，这也完全复合开闭原则（OCP）．
关于控制反转(IOC)
控制反转是一种设计模式，像单例，工厂，适合器都属于设计模式的一种，它是依赖倒置原则的具体实现，它告诉我们应该如何做，来解除相互依赖模块的耦合．
关于依赖注入(DI)
是IOC的一种实现方式，我们经常说的构造方法注入，属性注入，接口注入，指的就是DI，而我们经过说的unity,autofac,castle指的是DI的框架，即我们的IOC容器！
关于Lind.DDD.IoC容器
对于Lind.DDD.IoC模块来说,主要实现的功能是IoC和AoP，它在整个框架中都起到了底层支持的作用，如你的仓储在生产时，需要用到IoC；你的业务模块根据一个规则实现了多种策略，在生产这个业务模块时，需要用到IoC容器，而这个IoC容器可以通过服务定位器很方便找到你的依赖关系，坦白的说，对于所有对象的生产，都离不开服务定位器．
关于服务定位器(ServiceLocator)
一个程序集依赖别一个程序集，我们的服务定位器将帮助我们在Bin目录查找对应的依赖关系，帮我们生产对象；Lind.DDD里的服务定位器依赖了Lind的IocContainer，而新的IOC容器如果希望被服务定位器使用，我们只要实现IocContainer即可，这对于程序的扩展性是有好处的，目前Lind.IoC只集成了unity和autofac两种IoC容器.
关于Lind框架的IContainer
对所有第三方IoC容器的抽象，它只实现了最一般的IoC方法，如注入，反转，是否被注入等，具体看一下代码
/// <summary> /// IoC容器规范 /// 作者：仓储大叔 /// </summary> public interface IContainer { /// <summary> /// 反射成对象 /// </summary> /// <typeparam name="TService">接口类型</typeparam> /// <returns>具体类型</returns> TService Resolve<TService>(); /// <summary> /// 反射成对象 /// </summary> /// <typeparam name="TService">接口类型</typeparam> /// <returns>具体类型</returns> object Resolve(Type type); /// <summary> /// 反射成对象 /// </summary> /// <typeparam name="TService">接口类型</typeparam> /// <param name="overridedArguments">参数</param> /// <returns>具体类型</returns> TService Resolve<TService>(object overridedArguments); /// <summary> /// 反射成对象 /// </summary> /// <typeparam name="TService">接口类型</typeparam> /// <param name="overridedArguments">参数</param> /// <returns>具体类型</returns> object Resolve(Type serviceType, object overridedArguments); /// <summary> /// 注册抽象类型与具体实现的类型 /// </summary> /// <param name="from">接口类型</param> /// <param name="to">具体类型</param> void RegisterType(Type from, Type to); /// <summary> /// 类型是否被注册到IoC容器 /// </summary> /// <param name="type"></param> /// <returns></returns> bool IsRegistered(Type type); }
关于适配器模式
对于多种IoC容器的统一，我们借用了适配器模式，新添加了适配器类去实现我们自己的IContainer接口，在实现时，事实上是对原来第三方容器的重写，这种模式虽然添加了额外的类对象，但实现了对现有功能的扩展．
关于框架级的工厂模式
工厂模式一般不去实现，在业务层直接使用ioc容器生产对象即可，你使用工厂模块，一般都会有对象的switch这种坏味道的块出现，但对于比较稳定的框架对象来说，使用工厂模式还是比较不错的选择，因为你的框架实现是比较固定的，所以可以使用switch来进行策略的控制，从而生产指定的对象，当然对于不满足条件的，我们也应该手动throw出来，告诉开发人员．
结束语
希望大家都去自己写C#的框架，而不是每次都依赖从java共享出来的框架，感觉味道怪怪的，难道C#程度员真的这么懒呀！
哈哈！