Object Builder Application Block
文
/
黃忠成
2006/9/21
三、
ObjectBuilder Application Block
ObjectBuilde
r
一開始
出現於
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
![](https://p-blog.csdn.net/images/p_blog_csdn_net/Code6421/8eb4b10006f248728753c35a3f1eacd7.png)
圖
2
是
ObjectBuilder
中四個主要核心物件的示意圖,
BuidlerContext
是一個概念型的環境物件,在這個物件中,包含著一組
Strategys
物件,一組
Polices
物件,一個
Locato
r
物件, 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
![](https://p-blog.csdn.net/images/p_blog_csdn_net/Code6421/64d029fa33b34bf6923541756cc9f1eb.png)
值得一提的是,
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
![](https://p-blog.csdn.net/images/p_blog_csdn_net/Code6421/25fe36b92a83493a87253514cda2b08e.png)
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 Injectio
n
。而MethodExecutionStrategy則會與MethodReflectionStrategy合作,在物件建立後,呼叫特定的函式,也就是Method Injection(視使用方式,Interface Injection是以此種方式完成的)。
Post-Initialization Strategy
在物件建立並完成初始化動作後,就進入了
Post-Initialization Strateg
y
階段,在此階段中,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
strategies =
new
StrategyList
();
public
BuilderBase()
{
}
public
PolicyList Policies
{
get { return policies; }
}
public
StrategyList
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
(
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
最後一個尚未釐清的關鍵元素是
Locato
r
,我們於呼叫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
![](https://p-blog.csdn.net/images/p_blog_csdn_net/Code6421/103d5353257d40729df5ce8cb13514ef.png)
圖中讀者可能會有所迷惑的是,
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
![](https://p-blog.csdn.net/images/p_blog_csdn_net/Code6421/e126251accee45af8eb67bf6e7203946.png)
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
並未要求建構者傳入任何物件實體,而是要求建構者傳入注入時對應的參數型別、參數名稱、實體型別、
NotPersentBehavoi
r
及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
時所傳入的第三個參數相同。最後一個問題是,如果每個『型別/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
來建立物件,不同的是其不會先搜尋
Locato
r
,也無法作參數型別與實體型別對應,因此無法適用於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 Injectio
n
時,設計者必須在建立物件前,預先準備這些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
,否則建立一個新的
Dependenc
yParameter
,她會單以型別參數來建立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 Attribut
e
、或是使用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 Attribut
e
或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<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
有兩個特色,一是其會選擇頂端的建構子,二是其一律以
BuidU
p
函式依據參數型別來建立參數物件,不需要設計者介入。那在何種情況下選擇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
來完成,指的是在物件建立後,呼叫所指定的函式來完成初始化動作,而負責這個工作的就是
MethodExecutionStrateg
y
,本節持續延應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());
UseDependencyAttribute(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
物件。在
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 Injectio
n
,用法與前述的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 Wor
k
?
當
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
及
MethodReflectionStrateg
y
,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 Injectio
n
,如程式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;
}
}
...............
}
|
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1282150