Object Builder Application Block (2)
三、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提供以下的功能。
- 允許要求一個抽象對象或接口，ObjectBuilder會依據程序或組態文件的設定，傳回一個實體對象。
- 回傳一個既存對象，或是每次回傳一個新的對象(多半用于Dependency、Singleton情況，稍后會有詳細說明)。
- 透過特定的Factory建立一個對象，這個Factory可以依據組態文件的設定來建立對象(CustomFactory，隸屬于Enterprise Common Library)。
- 當物件擁有一個以上的構造函數時，依據已有的參數，自動選取兼容的構造函數來建立要求的對象。(Consturctor Injection)
- 允許對象于建立后，透過程序或組態文件來賦值至屬性，或是調用特定的方法。(Setter Injection、Interface Injection)
- 提供一組Attribute，讓設計師可以指定需要Injection的屬性，亦或是于對象建立后需要調用的方法，也就是使用Reflection來自動完成Injection動作。
- 提供IBuilerAware接口，實現此接口的對象，ObjectBuilder會于建立該對象后，調用OnBuildUp或是OnTearDown方法。
- 提供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<TestObject>(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<TStageEnum> strategies = new StrategyList<TStageEnum>();public BuilderBase()
{
}
public PolicyList Policies
{
??? get { return policies; }
}
public StrategyList<TStageEnum> Strategies
{
??? get { return strategies; }
}
public Builder(IBuilderConfigurator<BuilderStage> configurator)
{
??? Strategies.AddNew<TypeMappingStrategy>(BuilderStage.PreCreation);
??? Strategies.AddNew<SingletonStrategy>(BuilderStage.PreCreation);
??? Strategies.AddNew<ConstructorReflectionStrategy>(BuilderStage.PreCreation);
??? Strategies.AddNew<PropertyReflectionStrategy>(BuilderStage.PreCreation);
??? Strategies.AddNew<MethodReflectionStrategy>(BuilderStage.PreCreation);
??? Strategies.AddNew<CreationStrategy>(BuilderStage.Creation);
??? Strategies.AddNew<PropertySetterStrategy>(BuilderStage.Initialization);
??? Strategies.AddNew<MethodExecutionStrategy>(BuilderStage.Initialization);
??? Strategies.AddNew<BuilderAwareStrategy>(BuilderStage.PostInitialization);
??? Policies.SetDefault<ICreationPolicy>(new DefaultCreationPolicy());
??? if (configurator != null)
??????? configurator.ApplyConfiguration(this);
}
當Buidler對象被建立時，其構造函數會將前面所提及的幾個Strategys加到Strategies這個StrategyList Collection對象中，待BuildUp方法被調用時指定給新建立的BuilderContext對象。
public TTypeToBuild BuildUp<TTypeToBuild>(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<BuilderStage> configurator){
??? ..................
??? Policies.SetDefault<ICreationPolicy>(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<ICreationPolicy>(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<TestObject>("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<ICreationPolicy>(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<ICreationPolicy>(creationPolicy, typeof(InputAccept), null);
?
?? ConstructorPolicy creationPolicy2 = new ConstructorPolicy();
?? context.Policies.Set<ICreationPolicy>(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<ICreationPolicy>(creationPolicy, typeof(InputAccept), null);
??? ConstructorPolicy creationPolicy2 = new ConstructorPolicy();
??? context.Policies.Set<ICreationPolicy>(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<ICreationPolicy>時所傳入的第三個參數相同。最后一個問題是，如果每個『類型/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<ICreationPolicy>(creationPolicy, typeof(InputAccept), null);
??? context.Policies.SetDefault<ICreationPolicy>(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<ICreationPolicy>(creationPolicy, typeof(InputAccept), null);
??? TypeMappingPolicy mappingPolicy = new TypeMappingPolicy(typeof(PromptDataProcessor), null);
??? context.Policies.Set<ITypeMappingPolicy>(mappingPolicy, typeof(IDataProcessor), null);
??? context.Policies.SetDefault<ICreationPolicy>(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<ICreationPolicy>(creationPolicy, typeof(InputAccept), null);
??? context.Policies.SetDefault<ICreationPolicy>(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的四個屬性：
| 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的實現對象，一是前面所使用的ConstructorPolicy，二是DefaultCreationPolicy，與ConstructorPolicy不同，DefaultCreationPolicy永遠使用預設的構造函數，如下所示。
public ConstructorInfo SelectConstructor(IBuilderContext context, Type type, string id){
??? if (constructor != null)
??????? return constructor;
??? List<Type> types = new List<Type>();
??? 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());
??? IMethodCallInfo callInfo = new MethodCallInfo("SetDataProcessor", new ValueParameter(typeof(IDataProcessor),
??????? new PromptDataProcessor()));
??? IMethodPolicy policy = new MethodPolicy();
??? policy.Methods.Add("SetDataProcessor", callInfo);
??? context.Policies.Set<IMethodPolicy>(policy, typeof(InputAccept), null);
}
static void Main(string[] args)
{
??? MyBuilderContext context = new MyBuilderContext(new Locator());
??? UseMethodInfo(context);
??? context.Policies.SetDefault<ICreationPolicy>(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<IParameter> parameters)
public MethodCallInfo(MethodInfo method)
public MethodCallInfo(MethodInfo method, params IParameter[] parameters)
public MethodCallInfo(MethodInfo method, IEnumerable<IParameter> parameters)
MethodInfo擁有許多重載的構造函數，大概分成兩大類：方法名稱及MethodInfo對象，每類會分成四個，分別是無參數、使用params傳入參數值、使用params傳入IParamete對象、傳入IEnumerable<IParameter>對象。在MethodInfo對象建立后，接著就要將這些對象傳入IMethodPolicy對象，并指定給context.Policies對象，這樣就完成了Interface Injection的準備動作，之后建立InputAccept對象后，SetDataProcess方法就會被調用，同時會傳入指定的PromptDataProcessor對象。
- How MethodExecutionStrategy Working？
當MethodExecutionStrategy的BuildUp方法被調用時，會透過context.Policies來取得類型對應的IMethodPolicy對象，如下所示。
IMethodPolicy policy = context.Policies.Get<IMethodPolicy>(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<IParameter> ObjectsToIParameters(object[] parameters)
{
??? List<IParameter> results = new List<IParameter>();
??? 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<IMethodPolicy>(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<IPropertySetterPolicy>(policy, typeof(InputAccept), null);
}
static void Main(string[] args)
{
??? MyBuilderContext context = new MyBuilderContext(new Locator());
??? UsePropertySetter(context);
??? context.Policies.SetDefault<ICreationPolicy>(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<IPropertySetterPolicy>(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<IPropertySetterPolicy>(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;
??????? }
??? }
??? ...............
}
轉載于:https://www.cnblogs.com/sw22225458/archive/2008/06/12/1218695.html
總結
以上是生活随笔為你收集整理的Object Builder Application Block (2)的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 分辨率设置640*480
- 下一篇： lamp黄金组合apache+mysql