回到目錄

關於依賴倒置(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#程度員真的這麼懶呀！

哈哈！

回到目錄