回到目錄 關於依賴倒置(DIP) 高層模塊不依賴於低層模塊的實現，而低層模塊依賴於高層模塊定義的介面,通俗的講，就是高層模塊定義介面，低層模塊負責實現，這在我們實際開發中經常被用到，層與層之間引用，經常被添加一個介面層去隔離，在介面層定義相關業務規範，而底層去實現它，高層只引用這個介面，當高級需要其 ...
關於依賴倒置(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#程度員真的這麼懶呀！
哈哈！
