續上集,接著要談 Ambient Context 與 Service Locator 模式。
Ambient Context 模式
前述三種注入相依物件的方式,有些場合可能不適用,例如:應用程式特定執行環境的範圍內需要共享特定物件。碰到這種場合,便可以考慮採用 **Ambient Context **(環境脈絡)模式來解決。
Ambient Context又叫做 Context Object(環境物件),是一種常見的設計模式,主要用於跨階層、跨模組共享物件、界定程式執行區塊的範圍、以及提供橫切面的功能(cross-cutting concerns)。這些到處都需要的物件或服務,不太可能一一注入到每個需要它們的地方:一來過於繁瑣,二來有些子模組或程式區塊是碰觸不到、或不在控制範圍內的。因此,Ambient Context 沒有明顯「注入物件」的味道;它不是侵入性的,而是在某個地方已經準備好、被動地等著別人來取用。此特性在某些場合正好可以彌補前述注入方式的不足,故在此一併討論。
已知應用例
.NET 類別庫中提供交易管理功能的 System.Transactions.TransactionScope 就是 Ambient Context 的一個例子。以下程式片段示範了基礎用法。
using (TransactionScope trxScope = new TransactionScope())
{
// 執行多項資料異動作業。
order.Add(newOrder);
customer.LastOrderDate = DateTime.Now;
trxScope.Complete(); // 確認交易。
}
此外,ASP.NET 應用程式經常會用 Http.Web.HttpContext.Current 來取得目前的 HttpContext 物件。這也是一個常見的例子。
範例程式(一)
如前面提過的,Ambient Context 模式可用於程式特定執行範圍內共享物件狀態,此「特定範圍」可以是整個應用程式、特定執行緒、或其他自訂的執行範圍。如果是整個應用程式範圍內皆可存取的共享物件,實作起來相當容易,通常用一個公開的靜態類別和靜態屬性就能達成。例如以下程式片段:
public static AppShared
{
private static ILogger _logger = new MyLogger();
public static ILogger Logger
{
get { return _logger; }
set { _logger = value; }
}
}
每當應用程式需要寫入日誌訊息時,在任何地方皆可使用如下方式達成:
AppShared.Logger.Info("請謹慎使用靜態變數和全域變數。");
範例程式(二)
這裡再提供一個範例,示範如何實作一個依個別執行緒(per thread)共享物件資訊的 Ambient Context 類別。此類別會使用 .NET Framework 4.0 之後提供的 ThreadLocal<T> 來保存個別執行緒的狀態資訊。
令此 Ambient Context 類別名稱為 PerThreadContext,而且它要提供一個靜態的 Current 屬性,供外界取得當前的 context 物件。如此一來,用戶端程式可以透過以下方式取得當前執行緒 context 中的共享物件:
var obj = PerThreadContext.Current.SomeMember;
PerThreadContext 類別的程式碼如下:
public class PerThreadContext
{
// 用一個靜態的 ThreadLocal<T> 來管理各執行緒的 context 物件。
private static ThreadLocal<PerThreadContext> _threadedContext;
static PerThreadContext()
{
_threadedContext = new ThreadLocal<PerThreadContext>();
}
// 共享的狀態
public DateTime OnceUponATime { get; set; }
// 把建構函式宣告為私有,不讓外界任意 context 物件。
private PerThreadContext()
{
OnceUponATime = DateTime.Now;
}
public static PerThreadContext Current
{
get
{
// 如果目前的執行緒中沒有 context 物件...
if (_threadedContext.IsValueCreated == false)
{
// 就建立一個,並保存至 thread-local storage。
_threadedContext.Value = new PerThreadContext();
}
return _threadedContext.Value;
}
}
}
這裡使用了延遲初始化(lazy initialization)的技巧:當用戶端程式透過靜態屬性 Current 取得當下的 context 物件時,先檢查目前的執行緒中有沒有 context 物件,有則直接傳回物件參考,若沒有,便建立一個,並保存至目前執行緒專屬的儲存區(thread-local storage)。其中的公開物件屬性 OnceUponATime 代表要與其他物件共享的狀態。
我們可以用一個簡單的 Console 程式來觀察其運作機制:
static void Main(string[] args)
{
ShowTime();
System.Threading.Thread.Sleep(2000);
var t1 = new Thread(ShowTime);
var t2 = new Thread(ShowTime);
t1.Start();
System.Threading.Thread.Sleep(2000);
t2.Start();
System.Threading.Thread.Sleep(2000);
ShowTime();
/* 執行結果:
Thread 1: 2014/5/4 下午 01:37:09
Thread 3: 2014/5/4 下午 01:37:11
Thread 4: 2014/5/4 下午 01:37:13
Thread 1: 2014/5/4 下午 01:37:09
*/
}
static void ShowTime()
{
Console.WriteLine("Thread {0}: {1} ",
Thread.CurrentThread.ManagedThreadId,
PerThreadContext.Current.OnceUponATime);
}
執行結果顯示,同樣是印出 PerThreadContext.Current.OnceUponATime 屬性值,不同的執行緒會有不同的結果。
Service Locator 模式
Service Locator(服務定位器)是一種設計模式,它同時具有前面提過的 Ambient Context 和 Factory 模式的性質,而且經常與 DI 搭配使用(儘管頗具爭議),故在此一併介紹。
顧名思義,Service Locator 的功能是用來尋找應用程式所需的服務,並返回該服務的執行個體。說得更具體些,當用戶端需要特定介面(或抽象類別)的物件時,既不使用 new 來建立物件,也不使用注入物件的機制,而是向 Service Locator 要一個物件。其基本運作機制如下:
用戶端向 Service Locator 提出請求,要求一個符合 IServiceA 的物件。
Service Locator 透過本身的型別搜尋/對應機制來尋找符合(相容於) IServiceA 介面的具象類別,然後建立該類別的物件實體,並回傳給用戶端。
下圖為 Service Locator 模式的結構圖。
Service Locator 經常以 Singleton 的方式實作。這裡我採用 static 類別的方式來實作一個極陽春的 Service Locator。你也可以將它視為全域共享的 Ambient Context。類別名稱就叫做 ServiceLocator,程式碼如下。
public static class ServiceLocator
{
public static object GetService(Type requestedType)
{
if (requestedType is IMessageService)
{
return new EmailService();
}
else
{
// 略
}
}
}
若把先前的 AuthenticationService 範例改成使用此 ServiceLocator 來取得符合 IMessageService 介面的服務,程式碼會像這樣:
class AuthenticationService
class AuthenticationService
{
private readonly IMessageService msgService;
// 原本使用建構式注入
// 現在改用 Service Locator
public AuthenticationService()
{
this.msgService = ServiceLocator.GetService(IMessageService);
}
}
Note: 第 3 章介紹自製 DI 容器時,會有比較像樣的實作範例。
由於這種寫法太方便了,我們甚至可能懶得在建構函式中取得物件參考並保存至私有變數,而變成在程式中的任何地方、任何時候呼叫 ServiceLocator 來取得物件。然而,這裡有兩個問題必須注意。
首先,程式的語意變得比較隱晦,因而增加理解上的困難。進一步說,用戶端由於不再需要傳入相依物件至類別的建構函式,所以「瞄一眼建構函式就知道類別依賴哪些型別」的優點已經消失。同樣地,從用戶端程式碼也通常不容易看出此類別需要哪些相依物件。換言之,Service Locator 模式把物件實體化的相關資訊都隱藏起來了;這也是前面提過的,Service Locator 具有 Factory 性質的原因。
第二個問題是,AuthenticationService 原本使用「建構式注入」時並未依賴任何實作類別,改用 Service Locator 模式之後,卻依賴特定的具象類別 ServiceLocator 了。若推而廣之,在應用程式中大量使用此模式來取得相依物件,就會變成到處都依賴這個 ServiceLocator 類別。這於種大量依賴同一個類別的情形,如果該類別不是自己寫的,而是採用第三方元件,就得更慎重考慮其穩定性,以及是否會增加日後維護的麻煩。
基於上述兩個原因,許多人建議 Service Locator少用為妙。Mark Seemann 甚至直接把這種用法歸類為「反模式」(anti-pattern)。
小結
接著要談的是〈過度注入的陷阱與迷思〉,但我想,本系列就連載到這一集為止吧。如果您有興趣閱讀其餘內容,可前往書籍簡介與購買資訊線上購買這本電子書。
Happy coding!
from : http://huan-lin.blogspot.com/2011/11/dependency-injection-6.html
沒有留言:
張貼留言