C#基礎知識之依賴注入

目錄

1 IGame游戲公司的故事

    1.1 討論會

    1.2 實習生小李的實現方法

    1.3 架構師的建議

    1.4 小李的小結

2 探究依賴注入

    2.1 故事的啟迪

    2.2 正式定義依賴注入

3 依賴注入那些事兒

    3.1 依賴注入的類別

        3.1.1 Setter注入

        3.1.2 Construtor注入

        3.1.3 依賴獲取

    3.2 反射與依賴注入

    3.3 多態的活性與依賴注入

        3.3.1 多態性的活性

        3.3.2 不同活性多態性依賴注入的選擇

4 IoC Container

    4.1 IoC Container出現的必然性

    4.2 IoC Container的分類

        4.2.1 重量級IoC Container

        4.2.2 輕量級IoC Container

    4.3 .NET平台上典型IoC Container推介

        4.3.1 Spring.NET

        4.3.2 Unity

參考文獻

1 IGame游戲公司的故事

1.1 討論會

話說有一個叫IGame的游戲公司，正在開發一款ARPG游戲（動作&角色扮演類游戲，如魔獸世界、夢幻西游這一類的游戲）。一般這類游戲都有一個基本的功能，就是打怪（玩家攻擊怪物，借此獲得經驗、虛擬貨幣和虛擬裝備），並且根據玩家角色所裝備的武器不同，攻擊效果也不同。這天，IGame公司的開發小組正在開會對打怪功能中的某一個功能點如何實現進行討論，他們面前的大屏幕上是這樣一份需求描述的ppt：

 

 

圖1.1 需求描述ppt

各個開發人員，面對這份需求，展開了熱烈的討論，下面我們看看討論會上都發生了什么。

1.2 實習生小李的實現方式

　　在經過一番討論后，項目組長Peter覺得有必要整理一下各方的意見，他首先詢問小李的看法。小李是某學校計算機系大三學生，對游戲開發特別感興趣，目前是IGame公司的一名實習生。經過短暫的思考，小李闡述了自己的意見：“我認為，這個需求可以這么實現。HP當然是怪物的一個屬性成員，而武器是角色的一個屬性成員，類型可以使字符串，用於描述目前角色所裝備的武器。角色類有一個攻擊方法，以被攻擊怪物為參數，當實施一次攻擊時，攻擊方法被調用，而這個方法首先判斷當前角色裝備了什么武器，然后據此對被攻擊怪物的HP進行操作，以產生不同效果。”而在闡述完后，小李也飛快的在自己的電腦上寫了一個Demo，來演示他的想法，Demo代碼如下。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace IGameLi
{
    /// <summary>
    /// 怪物
    /// </summary>
    internal sealed class Monster
    {
        /// <summary>
        /// 怪物的名字
        /// </summary>
        public String Name { get; set; }
  
        /// <summary>
        /// 怪物的生命值
        /// </summary>
        public Int32 HP { get; set; }
  
        public Monster(String name,Int32 hp)
        {
            this.Name = name;
            this.HP = hp;
        }
    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace IGameLi
{
    /// <summary>
    /// 角色
    /// </summary>
    internal sealed class Role
    {
        private Random _random = new Random();
  
        /// <summary>
        /// 表示角色目前所持武器的字符串
        /// </summary>
        public String WeaponTag { get; set; }
  
        /// <summary>
        /// 攻擊怪物
        /// </summary>
        /// <param name="monster">被攻擊的怪物</param>
        public void Attack(Monster monster)
        {
            if (monster.HP <= 0)
            {
                Console.WriteLine("此怪物已死");
                return;
            }
  
            if ("WoodSword" == this.WeaponTag)
            {
                monster.HP -= 20;
                if (monster.HP <= 0)
                {
                    Console.WriteLine("攻擊成功！怪物" + monster.Name + "已死亡");
                }
                else
                {
                    Console.WriteLine("攻擊成功！怪物" + monster.Name + "損失20HP");
                }
            }
            else if ("IronSword" == this.WeaponTag)
            {
                monster.HP -= 50;
                if (monster.HP <= 0)
                {
                    Console.WriteLine("攻擊成功！怪物" + monster.Name + "已死亡");
                }
                else
                {
                    Console.WriteLine("攻擊成功！怪物" + monster.Name + "損失50HP");
                }
            }
            else if ("MagicSword" == this.WeaponTag)
            {
                Int32 loss = (_random.NextDouble() < 0.5) ? 100 : 200;
                monster.HP -= loss;
                if (200 == loss)
                {
                    Console.WriteLine("出現暴擊！！！");
                }
  
                if (monster.HP <= 0)
                {
                    Console.WriteLine("攻擊成功！怪物" + monster.Name + "已死亡");
                }
                else
                {
                    Console.WriteLine("攻擊成功！怪物" + monster.Name + "損失" + loss + "HP");
                }
            }
            else
            {
                Console.WriteLine("角色手里沒有武器，無法攻擊！");
            }
        }
    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace IGameLi
{
    class Program
    {
        static void Main(string[] args)
        {
            //生成怪物
            Monster monster1 = new Monster("小怪A", 50);
            Monster monster2 = new Monster("小怪B", 50);
            Monster monster3 = new Monster("關主", 200);
            Monster monster4 = new Monster("最終Boss", 1000);
  
            //生成角色
            Role role = new Role();
  
            //木劍攻擊
            role.WeaponTag = "WoodSword";
            role.Attack(monster1);
  
            //鐵劍攻擊
            role.WeaponTag = "IronSword";
            role.Attack(monster2);
            role.Attack(monster3);
  
            //魔劍攻擊
            role.WeaponTag = "MagicSword";
            role.Attack(monster3);
            role.Attack(monster4);
            role.Attack(monster4);
            role.Attack(monster4);
            role.Attack(monster4);
            role.Attack(monster4);
  
            Console.ReadLine();
        }
    }
}

 

程序運行結果如下：

 

 

 

圖1.2 小李程序的運行結果

1.3 架構師的建議

小李闡述完自己的想法並演示了Demo后，項目組長Peter首先肯定了小李的思考能力、編程能力以及初步的面向對象分析與設計的思想，並承認小李的程序正確完成了需求中的功能。但同時，Peter也指出小李的設計存在一些問題，他請小於講一下自己的看法。小於是一名有五年軟件架構經驗的架構師，對軟件架構、設計模式和面向對象思想有較深入的認識。他向Peter點了點頭，發表了自己的看法：“小李的思考能力是不錯的，有着基本的面向對象分析設計能力，並且程序正確完成了所需要的功能。不過，這里我想從架構角度，簡要說一下我認為這個設計中存在的問題。首先，小李設計的Role類的Attack方法很長，並且方法中有一個冗長的if…else結構，且每個分支的代碼的業務邏輯很相似，只是很少的地方不同。再者，我認為這個設計比較大的一個問題是，違反了OCP原則。在這個設計中，如果以后我們增加一個新的武器，如倚天劍，每次攻擊損失500HP，那么，我們就要打開Role，修改Attack方法。而我們的代碼應該是對修改關閉的，當有新武器加入的時候，應該使用擴展完成，避免修改已有代碼。一般來說，當一個方法里面出現冗長的if…else或switch…case結構，且每個分支代碼業務相似時，往往預示這里應該引入多態性來解決問題。而這里，如果把不同武器攻擊看成一個策略，那么引入策略模式（Strategy Pattern）是明智的選擇。

最后說一個小的問題，被攻擊后，減HP、死亡判斷等都是怪物的職責，這里放在Role中有些不當。”

Tip：OCP原則，即開放關閉原則，指設計應該對擴展開放，對修改關閉。

Tip：策略模式，英文名Strategy Pattern，指定義算法族，分別封裝起來，讓他們之間可以相互替換，此模式使得算法的變化獨立於客戶。

小於邊說，邊畫了一幅UML類圖，用於直觀表示他的思想。

 

 

圖1.3 小於的設計

Peter讓小李按照小於的設計重構Demo，小李看了看小於的設計圖，很快完成。相關代碼如下：

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace IGameLiAdv
{
    internal interface IAttackStrategy
    {
        void AttackTarget(Monster monster);
    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace IGameLiAdv
{
    internal sealed class WoodSword : IAttackStrategy
    {
        public void AttackTarget(Monster monster)
        {
            monster.Notify(20);
        }
    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace IGameLiAdv
{
    internal sealed class IronSword : IAttackStrategy
    {
        public void AttackTarget(Monster monster)
        {
            monster.Notify(50);
        }
    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace IGameLiAdv
{
    internal sealed class MagicSword : IAttackStrategy
    {
        private Random _random = new Random();
  
        public void AttackTarget(Monster monster)
        {
            Int32 loss = (_random.NextDouble() < 0.5) ? 100 : 200;
            if (200 == loss)
            {
                Console.WriteLine("出現暴擊！！！");
            }
            monster.Notify(loss);
        }
    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace IGameLiAdv
{
    /// <summary>
    /// 怪物
    /// </summary>
    internal sealed class Monster
    {
        /// <summary>
        /// 怪物的名字
        /// </summary>
        public String Name { get; set; }
  
        /// <summary>
        /// 怪物的生命值
        /// </summary>
        private Int32 HP { get; set; }
  
        public Monster(String name,Int32 hp)
        {
            this.Name = name;
            this.HP = hp;
        }
  
        /// <summary>
        /// 怪物被攻擊時，被調用的方法，用來處理被攻擊后的狀態更改
        /// </summary>
        /// <param name="loss">此次攻擊損失的HP</param>
        public void Notify(Int32 loss)
        {
            if (this.HP <= 0)
            {
                Console.WriteLine("此怪物已死");
                return;
            }
  
            this.HP -= loss;
            if (this.HP <= 0)
            {
                Console.WriteLine("怪物" + this.Name + "被打死");
            }
            else
            {
                Console.WriteLine("怪物" + this.Name + "損失" + loss + "HP");
            }
        }
    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace IGameLiAdv
{
    /// <summary>
    /// 角色
    /// </summary>
    internal sealed class Role
    {
        /// <summary>
        /// 表示角色目前所持武器
        /// </summary>
        public IAttackStrategy Weapon { get; set; }
  
        /// <summary>
        /// 攻擊怪物
        /// </summary>
        /// <param name="monster">被攻擊的怪物</param>
        public void Attack(Monster monster)
        {
            this.Weapon.AttackTarget(monster);
        }
    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace IGameLiAdv
{
    class Program
    {
        static void Main(string[] args)
        {
            //生成怪物
            Monster monster1 = new Monster("小怪A", 50);
            Monster monster2 = new Monster("小怪B", 50);
            Monster monster3 = new Monster("關主", 200);
            Monster monster4 = new Monster("最終Boss", 1000);
  
            //生成角色
            Role role = new Role();
  
            //木劍攻擊
            role.Weapon = new WoodSword();
            role.Attack(monster1);
  
            //鐵劍攻擊
            role.Weapon = new IronSword();
            role.Attack(monster2);
            role.Attack(monster3);
  
            //魔劍攻擊
            role.Weapon = new MagicSword();
            role.Attack(monster3);
            role.Attack(monster4);
            role.Attack(monster4);
            role.Attack(monster4);
            role.Attack(monster4);
            role.Attack(monster4);
  
            Console.ReadLine();
        }
    }
}

編譯運行以上代碼，得到的運行結果與上一版本代碼基本一致。

1.4 小李的小結

Peter顯然對改進后的代碼比較滿意，他讓小李對照兩份設計和代碼，進行一個小結。小李簡略思考了一下，並結合小於對一次設計指出的不足，說道：“我認為，改進后的代碼有如下優點：第一，雖然類的數量增加了，但是每個類中方法的代碼都非常短，沒有了以前Attack方法那種很長的方法，也沒有了冗長的if…else，代碼結構變得很清晰。第二，類的職責更明確了。在第一個設計中，Role不但負責攻擊，還負責給怪物減少HP和判斷怪物是否已死。這明顯不應該是Role的職責，改進后的代碼將這兩個職責移入Monster內，使得職責明確，提高了類的內聚性。第三，引入Strategy模式后，不但消除了重復性代碼，更重要的是，使得設計符合了OCP。如果以后要加一個新武器，只要新建一個類，實現IAttackStrategy接口，當角色需要裝備這個新武器時，客戶代碼只要實例化一個新武器類，並賦給Role的Weapon成員就可以了，已有的Role和Monster代碼都不用改動。這樣就實現了對擴展開發，對修改關閉。”Peter和小於聽后都很滿意，認為小李總結的非常出色。IGame公司的討論會還在進行着，內容是非常精彩，不過我們先聽到這里，因為，接下來，我們要對其中某些問題進行一點探討。別忘了，本文的主題可是依賴注入，這個主角還沒登場呢！讓主角等太久可不好。

 

2 探究依賴注入

2.1 故事的啟迪

我們現在靜下心來，再回味一下剛才的故事。因為，這個故事里面隱藏着依賴注入的出現原因。我說過不只一次，想真正認清一個事物，不能只看“它是什么？什么樣子？”，而應該先弄清楚“它是怎么來的？是什么樣的需求和背景促使了它的誕生？它被創造出來是做什么用的？”。回想上面的故事。剛開始，主要需求是一個打怪的功能。小李做了一個初步面向對象的設計：抽取領域場景中的實體（怪物、角色等），封裝成類，並為各個類賦予屬性與方法，最后通過類的交互完成打怪功能，這應該算是面向對象設計的初級階段。在小李的設計基礎上，架構師小於指出了幾點不足，如不符合OCP，職責划分不明確等等，並根據情況引入策略模式。這是更高層次的面向對象設計。其實就核心來說，小於只做了一件事：利用多態性，隔離變化。它清楚認識到，這個打怪功能中，有些業務邏輯是不變的，如角色攻擊怪物，怪物減少HP，減到0怪物就會死；而變化的僅僅是不同的角色持有不同武器時，每次攻擊的效用不一樣。於是他的架構，本質就是把變化的部分和不變的部分隔離開，使得變化部分發生變化時，不變部分不受影響。我們再仔細看看小於的設計圖，這樣設計后，有個基本的問題需要解決：現在Role不依賴具體武器，而僅僅依賴一個IAttackStrategy接口，接口是不能實例化的，雖然Role的Weapon成員類型定義為IAttackStrategy，但最終還是會被賦予一個實現了IAttackStrategy接口的具體武器，並且隨着程序進展，一個角色會裝備不同的武器，從而產生不同的效用。賦予武器的職責，在Demo中是放在了測試代碼里。這里，測試代碼實例化一個具體的武器，並賦給Role的Weapon成員的過程，就是依賴注入！這里要清楚，依賴注入其實是一個過程的稱謂！

2.2 正式定義依賴注入

下面，用稍微正式一點的語言，定義依賴注入產生的背景緣由和依賴注入的含義。在讀的過程中，讀者可以結合上面的例子進行理解。

依賴注入產生的背景：

隨着面向對象分析與設計的發展，一個良好的設計，核心原則之一就是將變化隔離，使得變化部分發生變化時，不變部分不受影響（這也是OCP的目的）。為了做到這一點，要利用面向對象中的多態性，使用多態性后，客戶類不再直接依賴服務類，而是依賴於一個抽象的接口，這樣，客戶類就不能在內部直接實例化具體的服務類。但是，客戶類在運作中又客觀需要具體的服務類提供服務，因為接口是不能實例化去提供服務的。就產生了“客戶類不准實例化具體服務類”和“客戶類需要具體服務類”這樣一對矛盾。為了解決這個矛盾，開發人員提出了一種模式：客戶類（如上例中的Role）定義一個注入點（Public成員Weapon），用於服務類（實現IAttackStrategy的具體類，如WoodSword、IronSword和MagicSword，也包括以后加進來的所有實現IAttackStrategy的新類）的注入，而客戶類的客戶類（Program，即測試代碼）負責根據情況，實例化服務類，注入到客戶類中，從而解決了這個矛盾。

依賴注入的正式定義：

依賴注入（Dependency Injection），是這樣一個過程：由於某客戶類只依賴於服務類的一個接口，而不依賴於具體服務類，所以客戶類只定義一個注入點。在程序運行過程中，客戶類不直接實例化具體服務類實例，而是客戶類的運行上下文環境或專門組件負責實例化服務類，然后將其注入到客戶類中，保證客戶類的正常運行。

3 依賴注入那些事兒

上面我們從需求背景的角度，講述了依賴注入的來源和定義。但是，如果依賴注入僅僅就只有這么點東西，那也沒有什么值得討論的了。但是，上面討論的僅僅是依賴注入的內涵，其外延還是非常廣泛的，從依賴注入衍生出了很多相關的概念與技術，下面我們討論一下依賴注入的“那些事兒”。

3.1 依賴注入的類別

依賴注入有很多種方法，上面看到的例子中，只是其中的一種，下面分別討論不同的依賴注入類型。

3.1.1 Setter注入

第一種依賴注入的方式，就是Setter注入，上面的例子中，將武器注入Role就是Setter注入。正式點說：

Setter注入（Setter Injection）是指在客戶類中，設置一個服務類接口類型的數據成員，並設置一個Set方法作為注入點，這個Set方法接受一個具體的服務類實例為參數，並將它賦給服務類接口類型的數據成員。

 

 

 

圖3.1 Setter注入示意

上圖展示了Setter注入的結構示意圖，客戶類ClientClass設置IServiceClass類型成員_serviceImpl，並設置Set_ServiceImpl方法作為注入點。Context會負責實例化一個具體的ServiceClass，然后注入到ClientClass里。

下面給出Setter注入的示例代碼。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace SetterInjection
{
    internal interface IServiceClass
    {
        String ServiceInfo();
    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace SetterInjection
{
    internal class ServiceClassA : IServiceClass
    {
        public String ServiceInfo()
        {
            return "我是ServceClassA";
        }
    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace SetterInjection
{
    internal class ServiceClassB : IServiceClass
    {
        public String ServiceInfo()
        {
            return "我是ServceClassB";
        }
    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace SetterInjection
{
    internal class ClientClass
    {
        private IServiceClass _serviceImpl;
  
        public void Set_ServiceImpl(IServiceClass serviceImpl)
        {
            this._serviceImpl = serviceImpl;
        }
  
        public void ShowInfo()
        {
            Console.WriteLine(_serviceImpl.ServiceInfo());
        }
    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace SetterInjection
{
    class Program
    {
        static void Main(string[] args)
        {
            IServiceClass serviceA = new ServiceClassA();
            IServiceClass serviceB = new ServiceClassB();
            ClientClass client = new ClientClass();
  
            client.Set_ServiceImpl(serviceA);
            client.ShowInfo();
            client.Set_ServiceImpl(serviceB);
            client.ShowInfo();
        }
    }
}

 

運行結果如下：

 

 

圖3.2 Setter注入運行結果

3.1.2 構造注入

另外一種依賴注入方式，是通過客戶類的構造函數，向客戶類注入服務類實例。

構造注入（Constructor Injection）是指在客戶類中，設置一個服務類接口類型的數據成員，並以構造函數為注入點，這個構造函數接受一個具體的服務類實例為參數，並將它賦給服務類接口類型的數據成員。

 

 

圖3.3 構造注入示意

圖3.3是構造注入的示意圖，可以看出，與Setter注入很類似，只是注入點由Setter方法變成了構造方法。這里要注意，由於構造注入只能在實例化客戶類時注入一次，所以一點注入，程序運行期間是沒法改變一個客戶類對象內的服務類實例的。

由於構造注入和Setter注入的IServiceClass，ServiceClassA和ServiceClassB是一樣的，所以這里給出另外ClientClass類的示例代碼。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace ConstructorInjection
{
    internal class ClientClass
    {
        private IServiceClass _serviceImpl;
  
        public ClientClass(IServiceClass serviceImpl)
        {
            this._serviceImpl = serviceImpl;
        }
  
        public void ShowInfo()
        {
            Console.WriteLine(_serviceImpl.ServiceInfo());
        }
    }
}

 

可以看到，唯一的變化就是構造函數取代了Set_ServiceImpl方法，成為了注入點。

3.1.3 依賴獲取

上面提到的注入方式，都是客戶類被動接受所依賴的服務類，這也符合“注入”這個詞。不過還有一種方法，可以和依賴注入達到相同的目的，就是依賴獲取。

依賴獲取（Dependency Locate）是指在系統中提供一個獲取點，客戶類仍然依賴服務類的接口。當客戶類需要服務類時，從獲取點主動取得指定的服務類，具體的服務類類型由獲取點的配置決定。

可以看到，這種方法變被動為主動，使得客戶類在需要時主動獲取服務類，而將多態性的實現封裝到獲取點里面。獲取點可以有很多種實現，也許最容易想到的就是建立一個Simple Factory作為獲取點，客戶類傳入一個指定字符串，以獲取相應服務類實例。如果所依賴的服務類是一系列類，那么依賴獲取一般利用Abstract Factory模式構建獲取點，然后，將服務類多態性轉移到工廠的多態性上，而工廠的類型依賴一個外部配置，如XML文件。

不過，不論使用Simple Factory還是Abstract Factory，都避免不了判斷服務類類型或工廠類型，這樣系統中總要有一個地方存在不符合OCP的if…else或switch…case結構，這種缺陷是Simple Factory和Abstract Factory以及依賴獲取本身無法消除的，而在某些支持反射的語言中（如C#），通過將反射機制的引入徹底解決了這個問題（后面討論）。

下面給一個具體的例子，現在我們假設有個程序，既可以使用Windows風格外觀，又可以使用Mac風格外觀，而內部業務是一樣的。

 

 

圖3.4 依賴獲取示意

上圖乍看有點復雜，不過如果讀者熟悉Abstract Factory模式，應該能很容易看懂，這就是Abstract Factory在實際中的一個應用。這里的Factory Container作為獲取點，是一個靜態類，它的“Type構造函數”依據外部的XML配置文件，決定實例化哪個工廠。下面還是來看示例代碼。由於不同組件的代碼是相似的，這里只給出Button組件的示例代碼，完整代碼請參考文末附上的完整源程序。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace DependencyLocate
{
    internal interface IButton
    {
        String ShowInfo();
    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace DependencyLocate
{
    internal sealed class WindowsButton : IButton
    {
        public String Description { get; private set; }
  
        public WindowsButton()
        {
            this.Description = "Windows風格按鈕";
        }
  
        public String ShowInfo()
        {
            return this.Description;
        }
    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace DependencyLocate
{
    internal sealed class MacButton : IButton
    {
        public String Description { get; private set; }
  
        public MacButton()
        {
            this.Description = " Mac風格按鈕";
        }
  
        public String ShowInfo()
        {
            return this.Description;
        }
    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace DependencyLocate
{
    internal interface IFactory
    {
        IWindow MakeWindow();
  
        IButton MakeButton();
  
        ITextBox MakeTextBox();
    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace DependencyLocate
{
    internal sealed class WindowsFactory : IFactory
    {
        public IWindow MakeWindow()
        {
            return new WindowsWindow();
        }
  
        public IButton MakeButton()
        {
            return new WindowsButton();
        }
  
        public ITextBox MakeTextBox()
        {
            return new WindowsTextBox();
        }
    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace DependencyLocate
{
    internal sealed class MacFactory : IFactory
    {
        public IWindow MakeWindow()
        {
            return new MacWindow();
        }
  
        public IButton MakeButton()
        {
            return new MacButton();
        }
  
        public ITextBox MakeTextBox()
        {
            return new MacTextBox();
        }
    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Xml;
  
namespace DependencyLocate
{
    internal static class FactoryContainer
    {
        public static IFactory factory { get; private set; }
  
        static FactoryContainer()
        {
            XmlDocument xmlDoc = new XmlDocument();
            xmlDoc.Load("http://www.cnblogs.com/Config.xml");
            XmlNode xmlNode = xmlDoc.ChildNodes[1].ChildNodes[0].ChildNodes[0];
  
            if ("Windows" == xmlNode.Value)
            {
                factory = new WindowsFactory();
            }
            else if ("Mac" == xmlNode.Value)
            {
                factory = new MacFactory();
            }
            else
            {
                throw new Exception("Factory Init Error");
            }
        }
    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace DependencyLocate
{
    class Program
    {
        static void Main(string[] args)
        {
            IFactory factory = FactoryContainer.factory;
            IWindow window = factory.MakeWindow();
            Console.WriteLine("創建 " + window.ShowInfo());
            IButton button = factory.MakeButton();
            Console.WriteLine("創建 " + button.ShowInfo());
            ITextBox textBox = factory.MakeTextBox();
            Console.WriteLine("創建 " + textBox.ShowInfo());
  
            Console.ReadLine();
        }
    }
}

 

這里我們用XML作為配置文件。配置文件Config.xml如下：

<?xml version="1.0" encoding="utf-8" ?>
<config>
    <factory>Mac</factory>
</config>

　　

可以看到，這里我們將配置設置為Mac風格，編譯運行上述代碼，運行結果如下：

 

 

圖3.5 配置Mac風格后的運行結果

現在，我們不動程序，僅僅將配置文件中的“Mac”改為Windows，運行后結果如下：

 

 

圖3.6 配置為Windows風格后的運行結果

從運行結果看出，我們僅僅通過修改配置文件，就改變了整個程序的行為（我們甚至沒有重新編譯程序），這就是多態性的威力，也是依賴注入效果。

本節共討論了三種基本的依賴注入類別，有關更多依賴注入類別和不同類別對比的知識，可以參考Martin Fowler的《Inversion of Control Containers and the Dependency Injection pattern》。

3.2 反射與依賴注入

回想上面Dependency Locate的例子，我們雖然使用了多態性和Abstract Factory，但對OCP貫徹的不夠徹底。在理解這點前，朋友們一定要注意潛在擴展在哪里，潛在會出現擴展的地方是“新的組件系列”而不是“組件種類”，也就是說，這里我們假設組件就三種，不會增加新的組件，但可能出現新的外觀系列，如需要加一套Ubuntu風格的組件，我們可以新增UbuntuWindow、UbuntuButton、UbuntuTextBox和UbuntuFactory，並分別實現相應接口，這是符合OCP的，因為這是擴展。但我們除了修改配置文件，還要無可避免的修改FactoryContainer，需要加一個分支條件，這個地方破壞了OCP。依賴注入本身是沒有能力解決這個問題的，但如果語言支持反射機制（Reflection），則這個問題就迎刃而解。

我們想想，現在的難點是出在這里：對象最終還是要通過“new”來實例化，而“new”只能實例化當前已有的類，如果未來有新類添加進來，必須修改代碼。如果，我們能有一種方法，不是通過“new”，而是通過類的名字來實例化對象，那么我們只要將類的名字作為配置項，就可以實現在不修改代碼的情況下，加載未來才出現的類。所以，反射給了語言“預見未來”的能力，使得多態性和依賴注入的威力大增。

下面是引入反射機制后，對上面例子的改進：

 

 

圖3.7 引入反射機制的Dependency Locate

可以看出，引入反射機制后，結構簡單了很多，一個反射工廠代替了以前的一堆工廠，Factory Container也不需要了。而且以后有新組件系列加入時，反射工廠是不用改變的，只需改變配置文件就可以完成。下面給出反射工廠和配置文件的代碼。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Reflection;
using System.Xml;
  
namespace DependencyLocate
{
    internal static class ReflectionFactory
    {
        private static String _windowType;
        private static String _buttonType;
        private static String _textBoxType;
  
        static ReflectionFactory()
        {
            XmlDocument xmlDoc = new XmlDocument();
            xmlDoc.Load("http://www.cnblogs.com/Config.xml");
            XmlNode xmlNode = xmlDoc.ChildNodes[1].ChildNodes[0];
  
            _windowType = xmlNode.ChildNodes[0].Value;
            _buttonType = xmlNode.ChildNodes[1].Value;
            _textBoxType = xmlNode.ChildNodes[2].Value;
        }
  
        public static IWindow MakeWindow()
        {
            return Assembly.Load("DependencyLocate").CreateInstance("DependencyLocate." + _windowType) as IWindow;
        }
  
        public static IButton MakeButton()
        {
            return Assembly.Load("DependencyLocate").CreateInstance("DependencyLocate." + _buttonType) as IButton;
        }
  
        public static ITextBox MakeTextBox()
        {
            return Assembly.Load("DependencyLocate").CreateInstance("DependencyLocate." + _textBoxType) as ITextBox;
        }
    }
}

 

配置文件如下：

<?xml version="1.0" encoding="utf-8" ?>
<config>
    <window>MacWindow</window>
    <button>MacButton</button>
    <textBox>MacTextBox</textBox>
</config>

　　

反射不僅可以與Dependency Locate結合，也可以與Setter Injection與Construtor Injection結合。反射機制的引入，降低了依賴注入結構的復雜度，使得依賴注入徹底符合OCP，並為通用依賴注入框架（如Spring.NET中的IoC部分、Unity等）的設計提供了可能性。

3.3 多態的活性與依賴注入

3.3.1 多態性的活性

這一節我們討論多態的活性及其與依賴注入類型選擇間密切的關系。

首先說明，“多態的活性”這個術語是我個人定義的，因為我沒有找到既有的概念名詞可以表達我的意思，所以就自己造了一個詞。這里，某多態的活性是指被此多態隔離的變化所發生變化的頻繁程度，頻繁程度越高，則活性越強，反之亦然。

上文說過，多態性可以隔離變化，但是，不同的變化，發生的頻率是不一樣的，這就使得多態的活性有所差別，這種差別影響了依賴注入的類型選擇。

舉例來說，本文最開始提到的武器多態性，其活性非常高，因為在那個程序中，Role在一次運行中可能更換多次武器。而現在我們假設Role也實現了多態性，這是很可能的，因為在游戲中，不同類型的角色（如暗夜精 靈、牛頭人、矮人等）很多屬性和業務是想通的，所以很可能通過一個IRole或AbstractRole抽象類實現多態性，不過，Role在實例化后（一般在用戶登錄成功后），是不會變化的，很少有游戲允許同一個玩家在運行中變換Role類型，所以Role應該是一但實例化，就不會變化，但如果再實例化一個（如另一個玩家登錄），則可能就變化了。最后，還有一種多態性是活性非常低的，如我們熟悉的數據訪問層多態性，即使我們實現了SQL Server、Oracle和Access等多種數據庫的訪問層，並實現了依賴注入，但幾乎遇不到程序運行着就改數據庫或短期內數據庫頻繁變動的情況。

以上不同的多態性，不但特征不同，其目的一般也不同，總結如下：

高活多態性——指在客戶類實例運行期間，服務類可能會改變的多態性。

中活多態性——指在客戶類實例化后，服務類不會改變，但同一時間內存在的不同實例可能擁有不同類型的服務類。

低活多態性——指在客戶類實例化后，服務類不會改變，且同一時間內所有客戶類都擁有相同類型的服務類。

以上三種多態性，比較好的例子就是上文提到的武器多態性（高活）、角色多態性（中活）和數據訪問層多態性（低活）。另外，我們說一種多態性是空間穩定的，如果同一客戶類在同一時間內的所有實例都依賴相同類型的服務類，反之則叫做空間不穩定多態性。我們說一種多態性是時間穩定的，如果一個客戶類在實例化后，所以來的服務類不能再次更改，反之則叫做時間不穩定多態性。顯然，高活多態性時間和空間均不穩定；中活多態性是時間穩定的，但空間不穩定；低活多態性時間空間均穩定。

3.3.2 不同活性多態的依賴注入選擇

一般來說，高活多態性適合使用Setter注入。因為Setter注入最靈活，也是唯一允許在同一客戶類實例運行期間更改服務類的注入方式。並且這種注入一般由上下文環境通過Setter的參數指定服務類類型，方便靈活，適合頻繁變化的高活多態性。

對於中活多態性，則適合使用Constructor注入。因為Constructor注入也是由上下文環境通過Construtor的參數指定服務類類型，但一點客戶類實例化后，就不能進行再次注入，保證了其時間穩定性。

而對於低活多態性，則適合使用Dependency Locate並配合文件配置進行依賴注入，或Setter、Constructor配合配置文件注入，因為依賴源來自文件，如果要更改服務類，則需要更改配置文件，一則確保了低活多態性的時間和空間穩定性，二是更改配置文件的方式方便於大規模服務類替換。（因為低活多態性一旦改變行為，往往規模很大，如替換整個數據訪問層，如果使用Setter和Construtor傳參，程序中需要改變的地方不計其數）

本質上，這種選擇是因為不同的依賴注入類型有着不同的穩定性，大家可以細細體會“活性”、“穩定性”和“依賴注入類型”之間密切的關系。

4 IoC Container

4.1 IoC Container出現的必然性

上面討論了諸多依賴注入的話題。說道依賴注入，就不能不說IoC Container（IoC容器），那么到底什么是IoC容器？我們還是先來看看它的出現背景。

我們知道，軟件開發領域有句著名的論斷：不要重復發明輪子！因為軟件開發講求復用，所以，對於應用頻繁的需求，總是有人設計各種通用框架和類庫以減輕人們的開發負擔。例如，數據持久化是非常頻繁的需求，於是各種ORM框架應運而生；再如，對MVC的需求催生了Struts等一批用來實現MVC的框架。

隨着面向對象分析與設計的發展和成熟，OOA&D被越來越廣泛應用於各種項目中，然而，我們知道，用OO就不可能不用多態性，用多態性就不可能不用依賴注入，所以，依賴注入變成了非常頻繁的需求，而如果全部手工完成，不但負擔太重，而且還容易出錯。再加上反射機制的發明，於是，自然有人開始設計開發各種用於依賴注入的專用框架。這些專門用於實現依賴注入功能的組件或框架，就是IoC Container。

從這點看，IoC Container的出現有其歷史必然性。目前，最著名的IoC也許就是Java平台上的Spring框架的IoC組件，而.NET平台上也有Spring.NET和Unity等。

4.2 IoC Container的分類

前面曾經討論了三種依賴注入方式，但是，想通過方式對IoC Container進行分類很困難，因為現在IoC Container都設計很完善，幾乎支持所有依賴注入方式。不過，根據不同框架的特性和慣用法，還是可以講IoC Container分為兩個大類。

4.2.1 重量級IoC Container

所謂重量級IoC Container，是指一般用外部配置文件（一般是XML）作為依賴源，並托管整個系統各個類的實例化的IoC Container。這種IoC Container，一般是承接了整個系統幾乎所有多態性的依賴注入工作，並承接了所有服務類的實例化工作，而且這些實例化依賴於一個外部配置文件，這種IoC Container，很像通過一個文件，定義整個系統多態結構，視野宏大，想要很好駕馭這種IoC Container，需要一定的架構設計能力和豐富的實踐經驗。

Spring和Spring.NET是重量級IoC Container的例子。一般來說，這種IoC Container穩定性有余而活性不足，適合進行低活多態性的依賴注入。

4.2.2 輕量級IoC Container

還有一種IoC Container，一般不依賴外部配置文件，而主要使用傳參的Setter或Construtor注入，這種IoC Container叫做輕量級IoC Container。這種框架很靈活，使用方便，但往往不穩定，而且依賴點都是程序中的字符串參數，所以，不適合需要大規模替換和相對穩定的低活多態性，而對於高活多態性，有很好的效果。

Unity是一個典型的輕量級IoC Container。

4.3 .NET平台上典型IoC Container推介

4.3.1 Spring.NET

 

Spring.NET是Java平台上Spring對.NET平台的移植，使用方法和Spring很像，並且功能強大，是.NET平台上大中型開發IoC Container的首選之一。除了DI外，Spring.NET也包括AOP等諸多功能。

Spring.NET的官方網站是：http://www.springframework.net/

4.3.2 Unity

 

對於小型項目和講求敏捷的團隊，Spring.NET可能有點太重量級，那么可以選擇輕量級的Unity。Unity是微軟patterns & practices團隊推出的輕量級框架，非常好用，目前最新版本是1.2。

Unity的官方網站是：http://unity.codeplex.com/

參考文獻

[1]  Shivprasad koirala, Design pattern – Inversion of control and Dependency injection, http://www.codeproject.com/KB/aspnet/IOCDI.aspx

[2]  Martin Fowler, Inversion of Control Containers and the Dependency Injection pattern, http://www.martinfowler.com/articles/injection.html

[3]  Paul, IoC Types, http://docs.codehaus.org/display/PICO/IoC+Types

[4]  Eric Freeman, Elisabeth Freeman. Head First Design Patterns. O’Reilly Media, 2004. ISBN 0596007142

[5]  Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. ISBN 0201633612

[6]  Patrick Smacchia 著，施凡等 譯，C#和.NET2.0 平台、語言與框架。2008.1，人民郵電出版

[7]  Jeffrey Rechter 著，CLR via C#（影印版）。2008.8，人民郵電出版