關于依賴倒置(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#程度員真的這么懶呀！
哈哈！
文章列表
留言列表
