C#中的依賴注入那些事兒

時間  2019-11-18
標籤 c# 依賴 注入 那些 事兒 欄目 C# 简体版
原文   原文鏈接

目錄

目錄html

1 IGame遊戲公司的故事算法

    1.1 討論會spring

    1.2 實習生小李的實現方法數據庫

    1.3 架構師的建議編程

    1.4 小李的小結設計模式

2 探究依賴注入架構

    2.1 故事的啓迪框架

    2.2 正式定義依賴注入dom

3 依賴注入那些事兒ide

    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代碼以下。

+ View Code ?
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;
         }
     }
}
+ View Code ?
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( "角色手裏沒有武器，沒法攻擊！" );
             }
         }
     }
}
+ View Code ?
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，小李看了看小於的設計圖，很快完成。相關代碼以下：

+ View Code ?
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace IGameLiAdv
{
     internal interface IAttackStrategy
     {
         void AttackTarget(Monster monster);
     }
}
+ View Code ?
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);
         }
     }
}
+ View Code ?
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);
         }
     }
}
+ View Code ?
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);
         }
     }
}
+ View Code ?
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" );
             }
         }
     }
}
+ View Code ?
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);
         }
     }
}
+ View Code ?
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注入的示例代碼。

+ View Code ?
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace SetterInjection
{
     internal interface IServiceClass
     {
         String ServiceInfo();
     }
}
+ View Code ?
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace SetterInjection
{
     internal class ServiceClassA : IServiceClass
     {
         public String ServiceInfo()
         {
             return "我是ServceClassA" ;
         }
     }
}
+ View Code ?
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace SetterInjection
{
     internal class ServiceClassB : IServiceClass
     {
         public String ServiceInfo()
         {
             return "我是ServceClassB" ;
         }
     }
}
+ View Code ?
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());
         }
     }
}
+ View Code ?
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類的示例代碼。

+ View Code ?
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組件的示例代碼，完整代碼請參考文末附上的完整源程序。

+ View Code ?
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace DependencyLocate
{
     internal interface IButton
     {
         String ShowInfo();
     }
}
+ View Code ?
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;
         }
     }
}
+ View Code ?
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;
         }
     }
}
+ View Code ?
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
  
namespace DependencyLocate
{
     internal interface IFactory
     {
         IWindow MakeWindow();
  
         IButton MakeButton();
  
         ITextBox MakeTextBox();
     }
}
+ View Code ?
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();
         }
     }
}
+ View Code ?
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();
         }
     }
}
+ View Code ?
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" );
             }
         }
     }
}
+ View Code ?
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以下：

+ View Code ?
<? 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也不須要了。並且之後有新組件系列加入時，反射工廠是不用改變的，只需改變配置文件就能夠完成。下面給出反射工廠和配置文件的代碼。

+ View Code ?
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;
         }
     }
}

配置文件以下：

+ View Code ?
<? 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，人民郵電出版

 

 

出處：http://www.cnblogs.com/leoo2sk/archive/2009/06/17/1504693.html

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程