Object Builder Application Block 文/黃忠成 2006/9/21 三、ObjectBuilder Application Block ObjectBuilder一開始出現於Microsoft所提出的Composite UI Application Block，主司物件的建立及釋放工作，她實現了本文前面所提及的Dependency Injection概念，同時在架構上提供了高度的延展性。運用ObjectBuilder來建立物件，設計師可以透過程式或組態檔，對物件建立與釋放的流程進行細部的調整，例如改變物件建立時所呼叫的Constructor(建構子)，調整傳入的參數，於物件建立後呼叫特定函式等等。鑑於ObjectBuilder的功能逐漸完整，加上社群對於Dependency Injection實作體的強烈需求，Microsoft正式將ObjectBuilder納入Enterprise Library 2006中，並修改Caching、Logger、Security、Data Access等Application Block的底層，令其於ObjectBuilder整合，以此增加這些Application Block的延展性。就官方文件的說明，ObjectBuilder Application Block提供以下的功能。表1
| l 允許要求一個抽象物件或介面，ObjectBuilder會依據程式或組態檔的設定，傳回一個實體物件。 |
| l 回傳一個既存物件，或是每次回傳一個新的物件(多半用於Dependency、Singleton情況，稍後會有詳細說明)。 |
| l 透過特定的Factory建立一個物件，這個Factory可以依據組態檔的設定來建立物件(CustomFactory，隸屬於Enterprise Common Library)。 |
| l 當物件擁有一個以上的建構子時，依據已有的參數，自動選取相容的建構子來建立要求的物件。(Consturctor Injection) |
| l 允許物件於建立後，透過程式或組態檔來賦值至屬性，或是呼叫特定的函式。(Setter Injection、Interface Injection) |
| l 提供一組Attribute，讓設計師可以指定需要Injection的屬性，亦或是於物件建立後需要呼叫的函式，也就是使用Reflection來自動完成Injection動作。 |
| l 提供IBuilerAware介面，實作此介面的物件，ObjectBuilder會於建立該物件後，呼叫OnBuildUp或是OnTearDown函式。 |
| l 提供TearDown機制，按建立物件的流程，反向釋放物件。 |
對於多數讀者來說，這些官方說明相當的隱誨，本文嘗試由架構角度切入，討論ObjectBuidler的主要核心概念，再透過實作讓讀者們了解，該如何使用ObjectBuidler。
3-1、The Architecture of Object Builder 圖2
圖2是ObjectBuilder中四個主要核心物件的示意圖，BuidlerContext是一個概念型的環境物件，在這個物件中，包含著一組Strategys物件，一組Polices物件，一個Locator物件， ObjectBuidler採用Strategys Pipeline(策略流)概念，設計師必須透過Strategy串列來建立物件，而Strategy會透過Polices來尋找『型別/id』對應的Policy物件，使用她來協助建立指定的物件。此處有一個必須特別提出來討論的概念，Strategy在架構上是與型別無關的，每個BuidlerContext會擁有一群Strategys物件，我們透過這個Strategys物件來建立任何型別的物件，不管建立的物件型別為何，都會通過這個Strategys Pipeline。這意味著，當我們希望於建立A型別物件後呼叫函式A1，於建立B型別物件後呼叫函式 B1時，負責呼叫函式的Strategy物件會需要一個機制來判別該呼叫那個函式，那就是Policy物件，BuilderContext中擁有一個Polices物件，其中存放著與『型別/id』對應的Policy物件，如圖3所示。圖3
值得一提的是，Policy是以Type/id方式，也就是『型別/id』方式來存放，這種做法不只可以讓不同型別擁有各自的Policy，也允許同型別但不同id擁有各自的Policy。ObjectBuilder中的最後一個元素是Locator，Locator物件在ObjectBuidler中扮演著前述的Service Locator角色，設計師可以用Key/Value的方式，將物件推入Locator中，稍後再以Key值來取出使用。
3-2、Strategys ObjectBuilder內建了許多Strategy，這些Strategy可以大略分成四種類型，如圖4。圖4
Pre-Creation Strategy Pre-Creation意指物件被建立前的初始動作，參與此階段的Strategy有：TypeMappingStrategy、PropertyReflectionStrategy、ConstructorReflectionStrategy、MethodReflectionStrategy及SingletonStrategy，稍後我們會一一檢視她們。
Creation Strategy Creation類型的Strategy主要工作在於建立物件，她會利用Pre-Creation Strategys所準備的參數來建立物件，ObjectBuilder就是運用Pre-Creation的ConstructorReflectionStrategy及CreationStrategy來完成Constructor Injection動作。
Initialization Strategy 當物件建立後，會進入初始化階段，這就是Initialization Strategy階段，在此階段中，PropertySetterStrategy會與PropertyReflectionStrategy合作，完成Setter Injection。而MethodExecutionStrategy則會與MethodReflectionStrategy合作，在物件建立後，呼叫特定的函式，也就是Method Injection(視使用方式，Interface Injection是以此種方式完成的)。
Post-Initialization Strategy 在物件建立並完成初始化動作後，就進入了Post-Initialization Strategy階段，在此階段中，BuilderAwareStrategy會探詢已建立的物件是否實作了IBuilderAware介面，是的話就呼叫IBuilderAware.OnBuildUp函式。
關於物件釋放 先前曾經提過，ObjectBuidler在建立物件時，會一一呼叫所有Strategy來建立物件，同樣的！當釋放物件時，ObjectBuilder也會進行同樣的動作，不過方向是相反的，在內建的Strategy中，只有BuilderAwareStrategy會參與物件釋放的動作，在物件釋放時，BuilderAwareStrategy會探詢欲釋放的物件是否實作了IBuidlerAware介面，是的話就呼叫IBuidlerAware.OnTearDown函式。
3-3、A Simple Application 再怎麼詳細的說明，少了一個實例就很難讓人理解，本節以一個簡單的ObjectBuidler應用實例開始，一步步帶領讀者進入ObjectBuilder的世界。程式10
| using System; using System.Collections.Generic; using System.Text; using Microsoft.Practices.ObjectBuilder; namespace SimpleApp { class Program { static void Main(string[] args) { Builder builder = new Builder(); TestObject obj = builder.BuildUp(new Locator(), null, null); obj.SayHello(); Console.ReadLine(); } } public class TestObject { public void SayHello() { Console.WriteLine("TEST"); } } } |
這是一個相當陽春的例子，在程式一開始時建立了一個Builder物件，她是ObjectBuilder所提供的Facade物件，其會預先建立一般常用的Strategy串列，並於BuilderUp函式被呼叫時，建立一個BuilderContext物件，並將Srategy串列及Polices串列指定給該BuilderContext，然後進行物件的建立工作。
How Object Creating 要了解前面的例子中，TestObject物件究竟是如何被建立起來的，首先必須深入Builder物件的建構動作。
| private StrategyList strategies = new StrategyList(); public BuilderBase() { } public PolicyList Policies { get { return policies; } } public StrategyList Strategies { get { return strategies; } } public Builder(IBuilderConfigurator configurator) { Strategies.AddNew(BuilderStage.PreCreation); Strategies.AddNew(BuilderStage.PreCreation); Strategies.AddNew(BuilderStage.PreCreation); Strategies.AddNew(BuilderStage.PreCreation); Strategies.AddNew(BuilderStage.PreCreation); Strategies.AddNew(BuilderStage.Creation); Strategies.AddNew(BuilderStage.Initialization); Strategies.AddNew(BuilderStage.Initialization); Strategies.AddNew(BuilderStage.PostInitialization); Policies.SetDefault(new DefaultCreationPolicy()); if (configurator != null) configurator.ApplyConfiguration(this); } |
當Buidler物件被建立時，其建構子會將前面所提及的幾個Strategys加到Strategies這個StrategyList Collection物件中，待BuildUp函式被呼叫時指定給新建立的BuilderContext物件。
| public TTypeToBuild BuildUp(IReadWriteLocator locator, string idToBuild, object existing, params PolicyList[] transientPolicies) { return (TTypeToBuild)BuildUp(locator, typeof(TTypeToBuild), idToBuild, existing, transientPolicies); } public virtual object BuildUp(IReadWriteLocator locator, Type typeToBuild, string idToBuild, object existing, params PolicyList[] transientPolicies) { .................... return DoBuildUp(locator, typeToBuild, idToBuild, existing, transientPolicies); ................... } private object DoBuildUp(IReadWriteLocator locator, Type typeToBuild, string idToBuild, object existing, PolicyList[] transientPolicies) { IBuilderStrategyChain chain = strategies.MakeStrategyChain(); .............. IBuilderContext context = MakeContext(chain, locator, transientPolicies); .......................... object result = chain.Head.BuildUp(context, typeToBuild, existing, idToBuild); ....................... } private IBuilderContext MakeContext(IBuilderStrategyChain chain, IReadWriteLocator locator, params PolicyList[] transientPolicies) { ............. return new BuilderContext(chain, locator, policies); } |
當Builder的泛型函式BuildUp函式被呼叫後，其會呼叫非泛型的BuildUp函式，該函式會呼叫DoBuildUp函式，此處會透過strategies(先前於Builder建構子時初始化的StrategyList物件)來取得Strategys串列，並指定給稍後由MakeContext函式建立的BuilderContext，最後呼叫Strategy串列中第一個Strategy的BuildUp函式來進行物件的建立動作。在這一連串的動作中，我們可以釐清幾個容易令人混淆的設計，第一！我們是透過Strategy串列，也就是IBuidlerStrategyChain.Head.BuildUp來建立物件，這個Head屬性就是Strategy串列中的第一個Strategy。第二！BuilderContext的作用在於，於呼叫各個Strategy.BuildUp函式時，給予她們存取此次建立動作所使用的Strategys及Policies等物件的機會。
Policy物件的用途 現在，我們弄清楚了Strategy的用途，BuilderContext的真正涵意，但還有兩個元素尚未釐清，其中之一就是Policy物件，前面曾經稍微提過，Strategy是與型別無關的設計概念，因此為了針對不同型別做個別的處理，我們需要另一個與型別相關的設計，那就是Policy物件，要確認這點，必須重返Builder的建構子。
| public Builder(IBuilderConfigurator configurator) { .................. Policies.SetDefault(new DefaultCreationPolicy()); ................. } |
這裡呼叫了Policies的SetDefault函式，Policies是一個PolicyList物件，其提供了推入(Set、SetDefault)及取出(Get)函式，允許設計者針對所有『型別/id』及特定『型別/id』指定對應的IBuilderPolicy物件，那這有什麼用呢？這個問題可以由CreationStrategy類別中的以下這段程式碼來回答。
| public override object BuildUp(IBuilderContext context, Type typeToBuild, object existing, string idToBuild) { if (existing != null) BuildUpExistingObject(context, typeToBuild, existing, idToBuild); else existing = BuildUpNewObject(context, typeToBuild, existing, idToBuild); return base.BuildUp(context, typeToBuild, existing, idToBuild); } [SecurityPermission(SecurityAction.Demand, Flags = SecurityPermissionFlag.SerializationFormatter)] private object BuildUpNewObject(IBuilderContext context, Type typeToBuild, object existing, string idToBuild) { ICreationPolicy policy = context.Policies.Get(typeToBuild, idToBuild); ......................... InitializeObject(context, existing, idToBuild, policy); return existing; } private void InitializeObject(IBuilderContext context, object existing, string id, ICreationPolicy policy) { ................ ConstructorInfo constructor = policy.SelectConstructor(context, type, id); ................... object[] parms = policy.GetParameters(context, type, id, constructor); ............... method.Invoke(existing, parms); } |
如你所見，CreationStrategy於建立物件時，會由Policies中取出『型別/id』對應的ICreationPolicy物件，接著利用她來取得ConstructorInfo(建構子函式)，再以GetParameters函式來取得建構子所需的參數，最後呼叫此建構子。這段程式碼告訴我們Policy的真正用途，就是用來協助Strategy於不同『型別/id』物件建立時，採取不同的動作，這也就是說，Strategy與Policy通常是成對出現的。
Locator 最後一個尚未釐清的關鍵元素是Locator，我們於呼叫Builder的BuildUp函式時，建立了一個Locator物件並傳入該函式，這是用來做什麼的呢？在ObjectBuilder中，Locator扮演兩種角色，第一個角色是提供一個物件容器供Strategy使用，這點可以透過以下程式了解。
| public class SingletonStrategy : BuilderStrategy { public override object BuildUp(IBuilderContext context, Type typeToBuild, object existing, string idToBuild) { DependencyResolutionLocatorKey key = new DependencyResolutionLocatorKey( typeToBuild, idToBuild); if (context.Locator != null && context.Locator.Contains(key, SearchMode.Local)) { TraceBuildUp(context, typeToBuild, idToBuild, ""); return context.Locator.Get(key); } return base.BuildUp(context, typeToBuild, existing, idToBuild); } } |
SingletonStrategy是一個用來維持某一個物件只能有一份實體存在，當此Strategy被喚起時，其會先至Locator尋找目前要求的物件是否已被建立，是的話就取出該物件並傳回。Locator同時也可以作為一個Service Locator，這點可以由以下程式碼來驗證。
| locator.Add("Test",new TestObject()); ............. TestObject obj = locator.Get("Test"); |
當然，這種手法有一個問題，那就是TestObject物件是預先建立後放在Locator中，這並不是一個好的設計，後面的章節我們會提出將Service Locator與Dependency Injection整合的手法。
| PS:ObjectBuidler的Locator離完善的Service Locator還有段距離。 |
四、Dependency Injection With ObjectBuilder ObjectBuilder支援Dependency Injection中定義的三種Injection模式，本章將一一介紹如何運用ObjectBuilder來實現。
4-1、Constructor Injection Constructor Injection的精神在於使用建構子來進行注入動作，本節延用InputAccept的例子，程式11是改採ObjectBuilder進行Constructor Injection的例子。程式11
| using System; using System.Collections.Generic; using System.Text; using System.Configuration; using Microsoft.Practices.ObjectBuilder; using Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ObjectBuilder; using Microsoft.Practices.EnterpriseLibrary.Common.Configuration; namespace OB_ConstructorInjectionTest { class Program { static void UseValueParameter(MyBuilderContext context) { ConstructorPolicy creationPolicy = new ConstructorPolicy(); creationPolicy.AddParameter(new ValueParameter(typeof(IDataProcessor), new PromptDataProcessor())); context.Policies.Set(creationPolicy, typeof(InputAccept), null); } static void Main(string[] args) { MyBuilderContext context = new MyBuilderContext(new Locator()); context.InnerChain.Add(new CreationStrategy()); UseValueParameter(context); InputAccept accept = (InputAccept)context.HeadOfChain.BuildUp(context, typeof(InputAccept), null, null); accept.Execute(); Console.Read(); } } internal class MyBuilderContext : BuilderContext { public IReadWriteLocator InnerLocator; public BuilderStrategyChain InnerChain = new BuilderStrategyChain(); public PolicyList InnerPolicies = new PolicyList(); public LifetimeContainer lifetimeContainer = new LifetimeContainer(); public MyBuilderContext() : this(new Locator()) { } public MyBuilderContext(IReadWriteLocator locator) { InnerLocator = locator; SetLocator(InnerLocator); StrategyChain = InnerChain; SetPolicies(InnerPolicies); if (!Locator.Contains(typeof(ILifetimeContainer))) Locator.Add(typeof(ILifetimeContainer), lifetimeContainer); } } public class InputAccept { private IDataProcessor _dataProcessor; public void Execute() { Console.Write("Please Input some words:"); string input = Console.ReadLine(); input = _dataProcessor.ProcessData(input); Console.WriteLine(input); } public InputAccept(IDataProcessor dataProcessor) { _dataProcessor = dataProcessor; } } public interface IDataProcessor { string ProcessData(string input); } public class DummyDataProcessor : IDataProcessor { #region IDataProcessor Members public string ProcessData(string input) { return input; } #endregion } public class PromptDataProcessor : IDataProcessor { #region IDataProcessor Members public string ProcessData(string input) { return "your input is: " + input; } #endregion } } |
程式於一開始時，建立了一個MyBuilderContext物件，會自行建立BuilderContext物件而不使用Builder物件的目的很單純，就是為了釐清個別Strategy究竟做了那些事，這點在使用Builder物件時，會因為內建的Strategy都已加入，而顯得有些模糊。在MyBuilderContext物件建立後，此處將一個CreationStrategy加到Strategy串列中，CreationStrategy這個Strategy被歸類為Creation階段，是真正建立物件的Strategy，緊接著UseValueParameter函式會被呼叫，這個函式中建立了一個ConstructorPolicy物件，並呼叫其AddParameter函式，加入一個ValueParameter物件，這個ValueParameter物件就對應著InputAccept的建構子所需的參數，CreationStrategy於物件建立後，會透過BuilderContext的Policies來取得『型別/id』對應的ICreationPolicy物件(本例就是ConstructorPolicy物件)，然後呼叫ICreationPolicy.SelectionConstructor函式，這個函式必須根據呼叫者已用ICreationPolicy.AddParameter所傳入的參數來選擇正確的建構子，然後再呼叫這個建構子並填入參數值來完成物件建立工作，圖5是這整個流程的示意圖。圖5
圖中讀者可能會有所迷惑的是，FormatterServices.GetSafeUninitializedObject函式是何作用？這是.NET Framework中一個建立物件的途徑，與一般new或是Activator.CreateInstance方式不同，GetSafeUninitializedObject函式並不會觸發該物件的建構子，只是單純的將物件建立起來而已，因此CreationStrategy才必須於最後呼叫對應的建構子。
Understanding Parameter 程式11中使用了一個ValueParameter物件，要知道這個物件的作用，我們得先了解Parameter在ObjectBuilder中所代表的意義，在三種注入模式中，有一個共通的規則，就是需要有參數來注入，Constructor Injection是透過建構子參數注入，而Interface Injection則是透過函數參數注入，Setter Injection則是透過屬性注入，因此參數是這三種注入模式都會用到的觀念，所以ObjectBuilder定義了IParameter介面，並提供一組實作此介面的參數物件，於注入時期由這些參數物件來取得參數值，如圖6。圖6
ValueParameter 這是一個最簡單的Paramter物件，建構子如下所示：
| public ValueParameter(Type valueType, object value) |
她的GetValue函式僅是將建構子傳入的value物件傳回而已。
DependencyParamter DependencyParameter是一個功能強大的Parameter物件，程式12是以DependencyParameter來取代ValueParameter完成Constructor Injection的例子。程式12
| static void UseDependencyParameter(MyBuilderContext context) { ConstructorPolicy creationPolicy = new ConstructorPolicy(); creationPolicy.AddParameter(new DependencyParameter(typeof(IDataProcessor),null, typeof(PromptDataProcessor),NotPresentBehavior.CreateNew,SearchMode.Local)); context.Policies.Set(creationPolicy, typeof(InputAccept), null); ConstructorPolicy creationPolicy2 = new ConstructorPolicy(); context.Policies.Set(creationPolicy2, typeof(PromptDataProcessor),null); } |
讀者可以發現，DependencyParameter並未要求建構者傳入任何物件實體，而是要求建構者傳入注入時對應的參數型別、參數名稱、實體型別、NotPersentBehavoir及SearchMode等參數，下面的程式列表是DependencyParameter的建構子：
| public DependencyParameter(Type parameterType, string name, Type createType, NotPresentBehavior notPresentBehavior, SearchMode searchMode) |
第一個參數是參數的型別，第二個參數是參數的名稱，當ConstructorPolicy於SelectConstructor函式時，會依據這兩個參數來選取適合的建構子，第三個參數是實體物件的型別，以本例來說，就是以PromptDataProcessor這個型別建立物件來傳入需要IDataProcessor型別的建構子、函式或屬性，第四個參數則影響了DependencyParameter的取值動作，預設情況下，DependencyParameter會先至Locator中取值，這個動作會受到第五個參數：SearchMode的影響(稍後會介紹這一部份)，如果找不到的話，就會依據此參數值來做動作，NotPersentBehavior這個列舉的定義如下：
| public enum NotPresentBehavior { CreateNew, ReturnNull, Throw, } |
CreateNew代表著當DependencyParameter於Locator找不到需要的值時，呼叫BuilderContext.HeadOfChain.BuildUp函式來建立該物件，以此例來說即是如此，所建立物件的型別就是PromptDataProcessor。ReturnNull則是回傳一個Null值，Throw則是直接拋出一個例外。好了，了解了整體流程後，現在讓我們一一釐清這個流程中剩下的部份，第一！於Locator找尋需要的值是什麼意思，試想一種情況，當我們在做Dependency Injection時，是否有某些欲注入物件是可重用的，也就是該物件可以只建立一個，注入多個不同的物件，讓這些物件共用這個注入物件，這就是DependencyParameter會先至Locator中找尋已推入的注入物件的原因，請參考程式13的例子。程式13
| static void UseDependencyParameter(MyBuilderContext context) { context.InnerLocator.Add(new DependencyResolutionLocatorKey(typeof(IDataProcessor), null), new PromptDataProcessor()); ConstructorPolicy creationPolicy = new ConstructorPolicy(); creationPolicy.AddParameter(new DependencyParameter(typeof(IDataProcessor), null,typeof(PromptDataProcessor),NotPresentBehavior.CreateNew,SearchMode.Local)); context.Policies.Set(creationPolicy, typeof(InputAccept), null); ConstructorPolicy creationPolicy2 = new ConstructorPolicy(); context.Policies.Set(creationPolicy2, typeof(PromptDataProcessor),null); } |
這個例子預先建立了一個PromptDataProcessor物件，並以DependencyResolutionLocatorKey封裝後推入Locator中，這樣一來，當DependencyParameter取值時，就會依據參數的『型別/id』至Locator找尋需要的值，此時就會得到我們所推入的PromptDataProcessor物件，而不是建立一個新的，另外！只要於AddParameter所傳入的DependencyParameter是以IDataProcessor為參數型別，並以null為id(名稱)的話，那麼永遠都會傳回我們所推入Locator的PromptDataProcessor物件。第二個要釐清的是SearchMode的涵意，在ObjectBuilder的架構上，Locator是可以有Parent/Child關係的，當DependencyParameter要找尋需要的物件時，如果SearchMode是Local的話，那麼這個搜尋動作只會搜尋該Locator自身，如果是Up的話，那麼在該Locator自身搜尋不到時，就會往Parent Locator搜尋。第三個要釐清的是第二個ConstructorPolicy的建立動作，還記得嗎？我們提過Policy是『型別/id』相關的，當DependencyParameter無法於Locator找到需要的物件而透過BuildUp來建立物件時，該『型別/id』同樣需要一個ICreationPolicy來對應，否則將會引發Missing Policy的例外，注意！DependencyParameter所使用的name參數必須與設定Set時所傳入的第三個參數相同。最後一個問題是，如果每個『型別/id』都要設定對應的ICreationPolicy，豈不累人，ObjectBuilder當然沒有這麼不人性化，我們可以呼叫Policies.SetDefault來為所有『型別/id』預設一個ICreationPolicy，如程式14所示。程式14
| static void UseDependencyParameter(MyBuilderContext context) { ConstructorPolicy creationPolicy = new ConstructorPolicy(); creationPolicy.AddParameter(new DependencyParameter(typeof(IDataProcessor), null,typeof(PromptDataProcessor),NotPresentBehavior.CreateNew,SearchMode.Local)); context.Policies.Set(creationPolicy, typeof(InputAccept), null); context.Policies.SetDefault(new ConstructorPolicy()); } |
CreationParameter 與DependencyParameter相同，CreationParameter也會透過BuildUp來建立物件，不同的是其不會先搜尋Locator，也無法作參數型別與實體型別對應，因此無法適用於InputAccept這種以介面為介質的注入方式，必須與TypeMappingStrategy(後述)合用才能解決，如程式15所示。程式15
| static void UseCreationParameter(MyBuilderContext context) { ConstructorPolicy creationPolicy = new ConstructorPolicy(); creationPolicy.AddParameter(new CreationParameter(typeof(IDataProcessor))); context.Policies.Set(creationPolicy, typeof(InputAccept), null); TypeMappingPolicy mappingPolicy = new TypeMappingPolicy(typeof(PromptDataProcessor), null); context.Policies.Set(mappingPolicy, typeof(IDataProcessor), null); context.Policies.SetDefault(new ConstructorPolicy()); } static void Main(string[] args) { MyBuilderContext context = new MyBuilderContext(new Locator()); context.InnerChain.Add(new TypeMappingStrategy()); context.InnerChain.Add(new CreationStrategy()); UseCreationParameter(context); InputAccept accept = (InputAccept)context.HeadOfChain.BuildUp(context, typeof(InputAccept), null, null); accept.Execute(); Console.Read(); } |
CloneParameter CloneParameter的建構子接受一個IParameter參數，當其GetValue函式被呼叫時，會透過從建構子指定的Parameter物件來取值，如果取得的值是實作了ICloneable介面的物件時，其將呼叫Clone函式來拷貝該值，否則傳回原值，下面的程式片斷是CloneParametr的建構子宣告。
| public CloneParameter(IParameter param) |
LookupParameter LookupParameter的建構子接受一個object型別的參數，當GetValue函式被呼叫時，會經由Locator.Get函式，以建構子所傳入的參數為鍵值，取得位於Locator中的值，下面的程式片斷為LookupParameter的建構子宣告。
| public LookupParameter(object key) |
程式16則是將InputAccept範例改為使用LookupParameter的版本。程式16
| static void UseLookupParameter(MyBuilderContext context) { context.InnerLocator.Add("dataProcessor", new PromptDataProcessor()); ConstructorPolicy creationPolicy = new ConstructorPolicy(); creationPolicy.AddParameter(new LookupParameter("dataProcessor")); context.Policies.Set(creationPolicy, typeof(InputAccept), null); context.Policies.SetDefault(new ConstructorPolicy()); } |
InjectionConstructor Attribute 使用Paramerer物件來進行Consturctor Injection時，設計者必須在建立物件前，預先準備這些Parameter物件，雖然動作不算繁鎖，但若全部物件的建立都要這麼做，未免有些沒有效率，為此！ObjectBuilder提供了另一種較為簡單的方法，就是利用InjectionConstructor這個Attribute，再搭配上ConstructorReflectionStrategy物件，自動的為設計者準備這些Parmeter物件，程式17是修改為InjectionConstructor模式的版本。程式17
| static void UseInjectionConstructorAttribute(MyBuilderContext context) { context.InnerChain.Add(new ConstructorReflectionStrategy()); context.InnerChain.Add(new CreationStrategy()); } .......... public class InputAccept { private IDataProcessor _dataProcessor; public void Execute() { Console.Write("Please Input some words:"); string input = Console.ReadLine(); input = _dataProcessor.ProcessData(input); Console.WriteLine(input); } [InjectionConstructor] public InputAccept([Dependency(Name="dataProcessor", CreateType=typeof(PromptDataProcessor))]IDataProcessor dataProcessor) { _dataProcessor = dataProcessor; } } |
要使用InjectionConstructor Attribute，我們必須在CreationStrategy這個Strategy前加入一個ConstructorReflectionStrategy物件，她會於建立物件動作時，探詢欲建立物件型別所提供的所有建構子，選取已標上InjectionConstrucor Attribute的那個為指定建構子，接著ConstructorReflectionStrategy會探詢該建構子的所有參數，查看是否標上Dependency Attribute，是的話就以其設定建立DependencyParameter，否則建立一個新的DependencyParameter，她會單以型別參數來建立DependencyParameter，最後ConstructorReflectionStrategy會以這些資訊來建立對應的ConstructorPolicy物件，完成整個物件建立動作。
Understanding Dependency Attribute ConstructorReflectionStrategy依賴兩個關鍵的Attribute，一個是用來標示指定建構子的InjectionConstructor Attribute，另一個則是用來標示參數該如何取得的Dependency Attribute，此Attribute有四個屬性，分別對應到DependencyParameter的四個屬性，如表2。表2
| DependencyAttribute | DependencyParameter | 說明 |
| Name | Name | id(名稱) |
| CreateType | CreateType | 欲建立物件的實體型別 |
| NotPersentBehavior | NotPersentBehavior | 當欲建立物件無法由Locator取得時的行為模式。 |
| SearchMode | SearchMode | 對Locator的搜尋法則。 |
使用Dependency Attribute與ConsturctorReflectionStrategy模式的優點是設計者不需花費時間一一建立Parameter物件，而缺點就是CreateType參數，由於ConstructorReflectionStrategy依賴著Dependency Attribute的CreateType參數來決定實際建立物件的型別，這使得設計者必須在標示Dependency Attribute時，一併指定這個參數，否則ConstructorReflectionStrategy將會以參數型別做為建立實際物件時的型別，而在本例中，我們無法建立一個IDataProcessor物件，這點降低了程式的可訂制性。那這要如何解決呢？簡單的方法是撰寫一個新的Dependency Attribute、或是使用TypeMappingStrategy，複雜的則是撰寫一個新的ConstructorReflectionStrategy，後面的章節我們會再重訪這個問題。
Injection with DependencyResolutionLocator 前面談到DependencyParameter時曾經提過，她會先至Locator中搜尋需要的參數值，那麼這也意味著，在使用ConstructorReflectionStrategy時，我們可以將參數值先行推入Locator中，這樣就可以避開指定CreateType了，如程式18所示。程式18
| static void UseDependencyResolution(MyBuilderContext context) { context.InnerChain.Add(new ConstructorReflectionStrategy()); context.InnerChain.Add(new CreationStrategy()); context.InnerLocator.Add(new DependencyResolutionLocatorKey(typeof(IDataProcessor), "dataProcessor"),new PromptDataProcessor()); } [InjectionConstructor] public InputAccept([Dependency(Name="dataProcessor")]IDataProcessor dataProcessor) |
當然，這仍然會有一個問題，那就是必須預先建立PromptDataProcessor物件，而非於InputAccept物件建立時期建立，這是在不撰寫自定Dependency Attribute或Strategy，亦或是使用TypeMappingStrategy情況下的簡易解法。
DefaultCreationPolicy and ConstructorPolicy ObjectBuilder內建了兩個ICreationPolicy的實作體，一是前面所使用的ConsturoctPolicy，二是DefaultCreationPolicy，與ConstructorPolicy不同，DefaultCationPolicy永遠使用預設的建構子，如下所示。
| public ConstructorInfo SelectConstructor(IBuilderContext context, Type type, string id) { if (constructor != null) return constructor; List types = new List(); foreach (IParameter parm in parameters) types.Add(parm.GetParameterType(context)); return type.GetConstructor(types.ToArray()); } |
而呼叫該建構子時所需的參數，則直接以BuildUp函式，依據參數的『型別/id』來建立，沒有與Parameter的互動。
| public object[] GetParameters(IBuilderContext context, Type type, string id, ConstructorInfo constructor) { ParameterInfo[] parms = constructor.GetParameters(); object[] parmsValueArray = new object[parms.Length]; for (int i = 0; i < parms.Length; ++i) parmsValueArray[i] = context.HeadOfChain.BuildUp(context, parms[i].ParameterType, null, id); return parmsValueArray; } |
由此可見，DefaultCreationPolicy有兩個特色，一是其會選擇頂端的建構子，二是其一律以BuidUp函式依據參數型別來建立參數物件，不需要設計者介入。那在何種情況下選擇DefaultCreationPolicy呢？一般來說，使用ConstructorPolicy時，因為其會依據設計者所加入的Parameter物件來選擇建構子，如果設計者未準備這些，那麼ConstructorPolicy將因無法取得適合的建構子而引發例外，雖然這點可以經由搭配ConstructorReflectionStrategy來解決，但使用ConstructorReflectionStrategy時必須搭配Dependency Attribtue及InjectionConstructor Attribute，所以也是個負擔。使用DefaultCreationPolicy就沒有這些問題了，缺點則是無法指定實際建立的參數物件型別，所以DefautlCreationPolicy通常被設定成預設的ICreationPolicy，主要作用在於當我們所建立的物件是簡單的，只有一個建構子，且不需要特別指定參數實際型別時，就交由她來處理，而需要特別處理的，就運用『型別/id』對應的ConstructorPolicy或是Dependency Attribute、Injection Constructor Attrbute搭配ConstructorReflectionStrategy來處理。
4-2、Interface Injection Interface Injection在ObjectBuidler中可以經由Method Injection來完成，指的是在物件建立後，呼叫所指定的函式來完成初始化動作，而負責這個工作的就是MethodExecutionStrategy，本節持續延應InputAccept來示範如何於ObjectBuidler中實現Interface Injection。
MethodExecutionStrategy 要實現Interface Injection，除了必須使用CreationStrategy來建立物件外，還要使用另一個Strategy：MethodExecutionStrategy，她會在物件建立完成後，執行指定的函式，程式19是使用MethodExecutionStrategy來實現Interface Injection的例子。程式19
| static void UseMethodInfo(MyBuilderContext context) { context.InnerChain.Add(new CreationStrategy()); context.InnerChain.Add(new MethodExecutionStrategy()); IMethodCallInfocallInfo = new MethodCallInfo("SetDataProcessor", new ValueParameter(typeof(IDataProcessor), new PromptDataProcessor())); IMethodPolicy policy = new MethodPolicy(); policy.Methods.Add("SetDataProcessor", callInfo); context.Policies.Set(policy, typeof(InputAccept), null); } static void Main(string[] args) { MyBuilderContext context = new MyBuilderContext(new Locator()); UseDependencyAttribute(context); context.Policies.SetDefault(new DefaultCreationPolicy()); InputAccept accept = (InputAccept)context.HeadOfChain.BuildUp(context, typeof(InputAccept), null, null); accept.Execute(); Console.Read(); } public class InputAccept { private IDataProcessor _dataProcessor; public void SetDataProcessor(IDataProcessor dataProcessor) { _dataProcessor = dataProcessor; } public void Execute() { Console.Write("Please Input some words:"); string input = Console.ReadLine(); input = _dataProcessor.ProcessData(input); Console.WriteLine(input); } } |
此處使用ValueParameter來進行呼叫指定函式時的參數注入動作，在使用MethodExecutionStrategy時，設計者必須先行建立呼叫函式時所需的MethodCallInfo物件，這是一個實作IMethodInfo介面的物件，設計者必須於此物件中指定欲呼叫的函式、及傳入的Parameter物件，下面是MethodInfo的建構子宣告。
| public MethodCallInfo(string methodName) public MethodCallInfo(string methodName, params object[] parameters) public MethodCallInfo(string methodName, params IParameter[] parameters) public MethodCallInfo(string methodName, IEnumerable parameters) public MethodCallInfo(MethodInfo method) public MethodCallInfo(MethodInfo method, params IParameter[] parameters) public MethodCallInfo(MethodInfo method, IEnumerable parameters) |
MethodInfo擁有許多重載的建構子，大概分成兩大類：函式名稱及MethodInfo物件，每類會分成四個，分別是無參數、使用params傳入參數值、使用params傳入IParamete物件、傳入IEnumerable物件。在MethodInfo物件建立後，接著就要將這些物件傳入IMethodPolicy物件，並指定給context.Policies物件，這樣就完成了Interface Injection的準備動作，之後建立InputAccept物件後，SetDataProcess函式就會被呼叫，同時會傳入指定的PromptDataProcessor物件。
How MethodExecutionStrategy Working？ 當MethodExecutionStrategy的BuildUp函式被呼叫時，會透過context.Policies來取得型別對應的IMethodPolicy物件，如下所示。
| IMethodPolicy policy = context.Policies.Get(type, id); |
然後會透過IMethodPolicy物件來取得所有需要處理的IMethodCallInfo物件，並一一呼叫其SelectMethod函式來取得欲呼叫函式，如下所示。
| MethodInfo methodInfo = methodCallInfo.SelectMethod(context, type, id); |
SelectMethod函式會依據當初建立此IMethodCallInfo物件時所指定的函式名稱、參數數量及型別來取得對應函式的MethodInfo物件。於取得MethodInfo物件後，緊接著就是透過IMethodCallInfo.GetParameters函式來取得呼叫此函式時需傳入的參數值，如下所示。
| object[] parameters = methodCallInfo.GetParameters(context, type, id, methodInfo); |
最後呼叫MethodInfo.Invoke函式來呼叫該函式就完成整個動作了。
| methodInfo.Invoke(obj, parameters); |
好了，這就是MethodExecutionStrategy的整個流程，現在我們要釐清幾個可能會令人困惑的問題，第一！當欲呼叫的函式是重載，有多個同名函式時，SelectMethod依據什麼來決定要呼叫那一個？答案是參數數量及型別。第二！當使用Parameter物件傳入MethodCallInfo物件的建構子時，GetParameters函式會透過Parameter.GetValue來取值，那麼當直接以object[]方式傳入MethodCallInfo的建構子時呢？答案是該建構子會逐個為傳入的object建立ValueParameter物件，如下所示。
| public MethodCallInfo(string methodName, params object[] parameters) :this(methodName, null, ObjectsToIParameters(parameters)) { } private static IEnumerable ObjectsToIParameters(object[] parameters) { List results = new List(); if (parameters != null) foreach (object parameter in parameters) results.Add(new ValueParameter(parameter.GetType(), parameter)); return results.ToArray(); } |
最後一個問題是，可以進行一個以上的函式呼叫嗎？答案是可以，建立對應的MethodCallInfo物件，並加到IMethodPolicy後即可，呼叫的順序則是依照MethodCallInfo加入IMethodPolicy的順序。。
Use DependencyParameter 與Constructor Injection相同，你也可以使用DependencyParameter來進行Interface Injection動作，如程式20。程式20
| static void UseDependencyParameter(MyBuilderContext context) { context.InnerChain.Add(new CreationStrategy()); context.InnerChain.Add(new MethodExecutionStrategy()); MethodCallInfo callInfo = new MethodCallInfo("SetDataProcessor", new DependencyParameter(typeof(IDataProcessor), "dataProcessor", typeof(PromptDataProcessor), NotPresentBehavior.CreateNew, SearchMode.Local)); IMethodPolicy policy = new MethodPolicy(); policy.Methods.Add("SetDataProcessor", callInfo); context.Policies.Set(policy, typeof(InputAccept), null); } |
use MethodReflectionStrategy 如同ConstructorReflectionStrategy的作用一樣，ObjectBuilder也提供了供Method Injection使用的MethodReflectionStrategy物件，要使用她，我們必須為欲進行Method Injection的函式標上InjectionMethod Attribute，如程式21所示。程式21
| static void UseDependencyResolverLocator(MyBuilderContext context) { context.InnerChain.Add(new CreationStrategy()); context.InnerChain.Add(new MethodReflectionStrategy()); context.InnerChain.Add(new MethodExecutionStrategy()); context.InnerLocator.Add(new DependencyResolutionLocatorKey(typeof(IDataProcessor), "dataProcessor"), new PromptDataProcessor()); } public class InputAccept { private IDataProcessor _dataProcessor; [InjectionMethod] public void SetDataProcessor( [Dependency(Name="dataProcessor"))]IDataProcessor dataProcessor) { _dataProcessor = dataProcessor; } ........... } |
本例使用DependencyResolutionLocatorKey模式進行注入動作，有了Constructor Injection部份的解說，相信讀者對這種模式已經了然於胸了。
Injection with Dependency Attribute and CreateType 同樣的，我們也可以在Dependency Attribute中指定CreateType來達到同樣的效果，如程式22所示。程式22
| static void UseDependencyAttribute(MyBuilderContext context) { context.InnerChain.Add(new CreationStrategy()); context.InnerChain.Add(new MethodReflectionStrategy()); context.InnerChain.Add(new MethodExecutionStrategy()); } public class InputAccept { private IDataProcessor _dataProcessor; [InjectionMethod] public void SetDataProcessor( [Dependency(Name="dataProcessor", CreateType=typeof(PromptDataProcessor))]IDataProcessor dataProcessor) { _dataProcessor = dataProcessor; } ............. } |
4-3、Setter Injection ObjectBuilder使用PropertySetterStrategy來進行Setter Injection，用法與前述的Interface Injection模式大致相同，如程式23所示。程式23
| static void UsePropertySetter(MyBuilderContext context) { context.InnerChain.Add(new CreationStrategy()); context.InnerChain.Add(new PropertySetterStrategy()); PropertySetterPolicy policy = new PropertySetterPolicy(); policy.Properties.Add("DataProcessor", new PropertySetterInfo("DataProcessor", new ValueParameter(typeof(IDataProcessor), new PromptDataProcessor()))); context.Policies.Set(policy, typeof(InputAccept), null); } static void Main(string[] args) { MyBuilderContext context = new MyBuilderContext(new Locator()); UsePropertySetter(context); context.Policies.SetDefault(new DefaultCreationPolicy()); InputAccept accept = (InputAccept)context.HeadOfChain.BuildUp(context, typeof(InputAccept), null, null); accept.Execute(); Console.Read(); } public class InputAccept { private IDataProcessor _dataProcessor; public IDataProcessor DataProcessor { get { return _dataProcessor; } set { _dataProcessor = value; } } public void Execute() { Console.Write("Please Input some words:"); string input = Console.ReadLine(); input = _dataProcessor.ProcessData(input); Console.WriteLine(input); } } |
設計者必須預先建立PropertySetterInfo物件，並為其指定欲設定的屬性名稱及參數，PropertySetterInfo是一個實作了IPropertySetterInfo介面的物件，其建構子宣告如下。
| public PropertySetterInfo(string name, IParameter value) public PropertySetterInfo(PropertyInfo propInfo, IParameter value) |
有了MethodCallInfo的經驗，讀者們對這些建構子應該不會有任何疑惑，應該會抱怨其不像MethodCallInfo般提供那麼多的選擇吧(笑)。在ProeprtySetterInfo建立後，接著只要將其加到IPropertySetterPolicy物件中，並依『型別/id』指定給context.Policies即可完成Setter Injection。
How PropertySetterStrategy Work？ 當PropertySetterStrategy的BuildUp函式被呼叫時，會透過context.Policies來取得型別對應的IPropertySetterPolicy物件，如下所示。
| IPropertySetterPolicy policy = context.Policies.Get(type, id); |
然後會透過IMethodPoliIPropertySetterPolicyy物件來取得所有需要處理的IPropertySetterInfo物件，並一一呼叫其SelectProperty函式來取得欲設定的屬性，如下所示。
| PropertyInfo propInfo = propSetterInfo.SelectProperty(context, type, id); |
SelectProperty函式會依據當初建立此IPropertySetterInfo物件時所指定的屬性名稱、參數來取得對應屬性的PropertyInfo物件。於取得PropertyInfo物件後，緊接著就是透過IPropertySetterInfo.GetValue函式來取得設定此屬性時需傳入的值，如下所示。
| object value = propSetterInfo.GetValue(context, type, id, propInfo); |
最後呼叫PropertyInfo.SetValue函式來設定屬性值就完成整個動作了。
| propInfo.SetValue(obj, value, null); |
這就是整個Setter Injection的流程，這裡只有一個問題，我們可以設定一個以上的屬性嗎？答案是肯定的，只要建立對應數量的PropertySetterInfo物件即可。
use DependencyParameter 同樣的，使用DependencyParameter也可以達到同樣的效果，如程式24。程式24
| static void UseDependencyParameter(MyBuilderContext context) { context.InnerChain.Add(new CreationStrategy()); context.InnerChain.Add(new PropertySetterStrategy()); PropertySetterPolicy policy = new PropertySetterPolicy(); policy.Properties.Add("DataProcessor", new PropertySetterInfo("DataProcessor", new DependencyParameter(typeof(IDataProcessor),"DataProcessor", typeof(PromptDataProcessor),NotPresentBehavior.CreateNew,SearchMode.Local))); context.Policies.Set(policy, typeof(InputAccept), null); } |
use PropertyReflectionStrategy 相對於ConsturctorReflectionStrategy及MethodReflectionStrategy，ObjectBuilder也提供了一個同類型的PropertyReflectionStrategy，我們可以搭配Dependency Attribute及DependencyResolutionLocatorKey物件來達到同樣效果，如程式25。程式25
| static void UseDependencyResolutionLocator(MyBuilderContext context) { context.InnerChain.Add(new CreationStrategy()); context.InnerChain.Add(new PropertyReflectionStrategy()); context.InnerChain.Add(new PropertySetterStrategy()); context.Locator.Add(new DependencyResolutionLocatorKey(typeof(IDataProcessor), "DataProcessor"), new PromptDataProcessor()); } public class InputAccept { private IDataProcessor _dataProcessor; [Dependency(Name="DataProcessor")] public IDataProcessor DataProcessor { get { return _dataProcessor; } set { _dataProcessor = value; } } ......... } |
Injection with Dependency Attribute and CreateType 我們也可以使用Dependency Attribute及CreateType參數來進行Setter Injection，如程式26。程式26
| static void UseDependencyAttribute(MyBuilderContext context) { context.InnerChain.Add(new CreationStrategy()); context.InnerChain.Add(new PropertyReflectionStrategy()); context.InnerChain.Add(new PropertySetterStrategy()); } public class InputAccept { private IDataProcessor _dataProcessor; [Dependency(Name="DataProcessor",CreateType=typeof(PromptDataProcessor))] public IDataProcessor DataProcessor { get { return _dataProcessor; } set { _dataProcessor = value; } } ............... } |
v
Trackback:
http://tb.blog.csdn.net/TrackBack.aspx?PostId=1282150
