應(yīng)該注意，按照POJO/POCO的嚴(yán)格定義，我們的領(lǐng)域模型類不應(yīng)該繼承基礎(chǔ)架構(gòu)基類。不過(guò)，我們可以很容易改過(guò)來(lái)，只要將所有的邏輯從公共基類移到代理子類中去，就可以得到一個(gè)完全的POJO/POCO領(lǐng)域模型。如果一定要滿足嚴(yán)格的POJO/POCO，我們的方法很容易滿足這項(xiàng)要求，只是舉手之勞。如果不強(qiáng)求，我們可以使用基類，此時(shí)領(lǐng)域模型類的代碼仍然完全不包含任何實(shí)際的基礎(chǔ)架構(gòu)代碼。

因此到目前為止我們已經(jīng)整理出了一個(gè)架構(gòu)，能讓我們把完全POJO/POCO的領(lǐng)域模型類和將基礎(chǔ)架構(gòu)代碼分布到領(lǐng)域模型中去的目標(biāo)結(jié)合在一起。如果我們的目標(biāo)僅僅是避免肥領(lǐng)域模型，而不強(qiáng)求符合POJO/POCO定義，那么我們就能走“半POJO/POCO”的路線，用一個(gè)公共基類來(lái)節(jié)省一些工作。

使用抽象工廠模式

這聽(tīng)起來(lái)很棒，對(duì)不對(duì)？你可能在想，用它是不是沒(méi)有任何問(wèn)題呢。軟件業(yè)的人都有些吹毛求疵，你大概已經(jīng)在疑心有那么一兩個(gè)棘手問(wèn)題該冒頭了吧。

你是對(duì)的。有兩件值得關(guān)注的事情馬上就自己顯現(xiàn)出來(lái)了。第一個(gè)相當(dāng)輕微：為了讓子類能夠重寫領(lǐng)域模型類的成員，并提供攔截，所有的領(lǐng)域模型成員（或至少打算攔截的那些成員）必須是虛擬的。

第二個(gè)問(wèn)題好像更為糟糕一些：既然你想讓你的程序使用代理子類的實(shí)例，你必須在應(yīng)用代碼中查找所有創(chuàng)建領(lǐng)域模型類實(shí)例的地方，將它們改成創(chuàng)建相應(yīng)的代理子類的實(shí)例。

要修改已存在的應(yīng)用，聽(tīng)起來(lái)像個(gè)噩夢(mèng)吧？沒(méi)錯(cuò)。要想避免這種大規(guī)模的查找和替換操作，只有一條出路，就是從一開(kāi)始就避免使用“new”關(guān)鍵字來(lái)創(chuàng)建領(lǐng)域模型類的實(shí)例。

避免"new"的傳統(tǒng)方法就是使用抽象工廠模式[GoF設(shè)計(jì)模式]。調(diào)用一個(gè)工廠類的Create()方法，而不是任由客戶代碼使用“new”來(lái)創(chuàng)建實(shí)例。Create()方法負(fù)責(zé)調(diào)用“new”，并且在返回新的實(shí)例之前會(huì)對(duì)其做一些額外的相關(guān)設(shè)置操作。

如果你在調(diào)用領(lǐng)域模型的時(shí)候全都使用抽象工廠模式，那就最好不過(guò)了，接下來(lái)你只要在代碼中改一個(gè)地方——工廠類——將返回領(lǐng)域類實(shí)例改為返回代理子類（或者是基于接口的代理）的實(shí)例。

這是使用抽象工廠模式來(lái)實(shí)例化所有的領(lǐng)域?qū)ο蟮囊粋€(gè)重要理由——至少使用像Java和C#這樣的語(yǔ)言時(shí)是這樣，這些語(yǔ)言不允許奇異特性，比如不能像C++一樣重載（overload）成員取用運(yùn)算子，不能像ObjectiveC一樣改變“new”關(guān)鍵字的行為，也不能像Ruby一樣在運(yùn)行時(shí)修改類。

繼承反射

對(duì)于代理子類的方法，還有一個(gè)問(wèn)題值得一提。雖然只是一種極端情況，但是它相當(dāng)隱蔽，如果你陷入這個(gè)問(wèn)題卻不知道是什么引起的，會(huì)被它狠狠咬上一口。

如果你看一下圖9，你會(huì)發(fā)現(xiàn)Employee繼承Person類，這是應(yīng)該的：無(wú)論什么時(shí)候，如果一個(gè)方法期望Person對(duì)象，那么傳遞給它Employee對(duì)象應(yīng)該也能工作。此外，PersonProxy類繼承Person類。這也很好，因?yàn)檫@意味著將一個(gè)PersonProxy對(duì)象作為參數(shù)傳遞給期望Person對(duì)象的方法也是“合法的”。

以同樣的方式，EmployeeProxy繼承Employee，意味著你能把一個(gè)EmployeeProxy對(duì)象作為參數(shù)傳遞給任何期望Employee對(duì)象的方法。最后，由于EmployeeProxy繼承Employee，Employee又繼承Person，這表明EmployeeProxy繼承Person。因此，任何期望Person對(duì)象的方法也可以接受EmployeeProxy對(duì)象。

所有一切都符合我們的期望。當(dāng)我們讓抽象工廠開(kāi)始返回代理對(duì)象而不是領(lǐng)域模型類的簡(jiǎn)單實(shí)例時(shí)，有一點(diǎn)是很重要的，我們希望客戶端代碼仍然繼續(xù)正常運(yùn)行，而無(wú)需重新考慮如何處理我們的類型層次。

換句話說(shuō)，如果我們?cè)瓉?lái)向一個(gè)期望Person對(duì)象的方法傳遞Employee對(duì)象給，當(dāng)我們忽然換成給它傳遞EmployeeProxy對(duì)象的時(shí)候，我們的代碼必須還能正常編譯（并且工作）。幸運(yùn)的是，由于EmployeeProxy繼承Employee，并且Employee繼承Person，所以沒(méi)有問(wèn)題。

事實(shí)上，當(dāng)開(kāi)始使用代理來(lái)代替領(lǐng)域模型對(duì)象時(shí)，一切都將如常繼續(xù)運(yùn)轉(zhuǎn)，正如我們希望的。只不過(guò)，有一個(gè)個(gè)非常微小的例外。

圖9中的紅色繼承線表示EmployeeProxy不繼承PersonProxy。這什么時(shí)候會(huì)帶來(lái)問(wèn)題呢？

好，考慮一下這樣一個(gè)方法，它接受兩個(gè)對(duì)象，并用反射來(lái)確定其中一種對(duì)象是否是另一種對(duì)象的子類。當(dāng)我們把一個(gè)Person對(duì)象和一個(gè)Employee對(duì)象傳遞給該方法時(shí)，它會(huì)返回true。但是當(dāng)我們把一個(gè)PersonProxy對(duì)象和一個(gè)EmployeeProxy對(duì)象傳遞給該方法時(shí)，突然它就返回false了。

除非你有基于反射的、檢查繼承層次的代碼，不然應(yīng)該是安全的。但是萬(wàn)一你真的有這樣的代碼，這里先警告一下也沒(méi)壞處（你可以通過(guò)修改反射代碼來(lái)避開(kāi)這個(gè)問(wèn)題，讓它檢測(cè)代理類型，并一路向上直到找到一個(gè)非代理類型）。

使用混入（Mixin）和攔截器類

我們已經(jīng)向著可維護(hù)的領(lǐng)域模型架構(gòu)努力了很長(zhǎng)時(shí)間，讓它能容下一個(gè)有效率的、可訪問(wèn)的基礎(chǔ)架構(gòu)來(lái)實(shí)行運(yùn)行時(shí)領(lǐng)域模型管理。

我們是否可以做得更多呢？

讓我們開(kāi)始看一下那些只針對(duì)某些領(lǐng)域類、而不是全部領(lǐng)域類的功能——對(duì)于這些功能，我們需要將所需的基礎(chǔ)架構(gòu)成員放在代理子類中，而不是在公用的基類中。在我們的例子中，為懶加載功能設(shè)置的加載標(biāo)記將必須添加到需要支持懶加載的每個(gè)類的子類中。

由于我們可能需要在多個(gè)子類中放相同的代碼，所以我們明顯會(huì)導(dǎo)致代碼重復(fù)。只有一個(gè)標(biāo)記的時(shí)候情況還好，但是對(duì)于需要多個(gè)屬性、甚至需要多個(gè)有復(fù)雜實(shí)現(xiàn)的方法的功能呢？

在我們的例子中，加載標(biāo)記是一次寫入（write-once），所以在變成true之后不能再切換回來(lái)。因此，在setter方法中，我們有一些代碼來(lái)實(shí)施這個(gè)規(guī)則——在需要懶加載的每個(gè)領(lǐng)域模型類的子類中，我們都要在setter方法中重復(fù)的那些代碼。

一個(gè)很好的答案就是使用組合模式[GoF Design Patterns]，而不是為此采用繼承。使用這種模式，EmployeeProxy子類將包含一個(gè)內(nèi)部屬性來(lái)引用可重用的懶加載類的實(shí)例（圖10）。

這種可重用的類常常被稱為混入（mixin），它反映了這樣一個(gè)事實(shí)，即實(shí)現(xiàn)被加入到類型中，而不是成為繼承層次的一部分。使用混入的作用是，讓單繼承語(yǔ)言（甚至是在只支持接口繼承的平臺(tái)上，比如COM+）也能夠獲得類似多重繼承的效果。

有一點(diǎn)可以補(bǔ)充說(shuō)明一下，使用我們這種組合方式，以混入的形式存在的行為和狀態(tài)能動(dòng)態(tài)地被加到目標(biāo)類中（使用依賴注入），而不是靜態(tài)地綁定到目標(biāo)上去（如果行為是繼承下來(lái)的就會(huì)如此）。盡管在這篇文章中我們不會(huì)更多關(guān)注于如何利用它的潛能，但是它為支持一些非常靈活和動(dòng)態(tài)的場(chǎng)景提供了非常大的空間。

通過(guò)將子類引入的成員分離到一個(gè)可重用的混入類，我們向一個(gè)真正模塊化、一致的、內(nèi)聚的架構(gòu)邁進(jìn)了一大步，這個(gè)架構(gòu)還是低耦合的、高度代碼可重用的。我們能向這個(gè)方向再進(jìn)一步嗎？

那么，接下來(lái)要做的事就是把攔截代碼從子類中分離出來(lái)，并放到可重用的類里面。這些攔截器類會(huì)像混入一樣包含在代理子類里面，如圖11.

Person、Employee和DomainBase與代碼的上一個(gè)版本保持不變，但是PersonProxy和EmployeeProxy發(fā)生了變化，并且我們引入了兩個(gè)新的攔截器類和一個(gè)新的混入類。清單5顯示了我們進(jìn)行這些重構(gòu)（不包括未修改的類）之后代碼的樣子。

//These proxy subclasses contain only boilerplate

    //code now. All actual logic has been refactored

    //out into mixin and interceptor classes.

    public class PersonProxy : Person

    {

    private DirtyInterceptor dirtyInterceptor = new DirtyInterceptor();

    

    public override string Name

    {

    get { return base.Name; }

    set

    {

    dirtyInterceptor.OnPropertySet(this, this.name, value);

    base.Name = value;

    }

    }

    }

    

    public class EmployeeProxy : Employee, ILazy

    {

    //This mixin contains the implementation

    //of the ILazy interface.

    private ILazy lazyMixin = new LazyMixin();

    

    private LazyInterceptor lazyInterceptor = new LazyInterceptor();

    private DirtyInterceptor dirtyInterceptor = new DirtyInterceptor();

    

    public override string Name

    {

    get

    {

    lazyInterceptor.OnPropertyGetSet(this, "Name");

    return base.Name;

    }

    set

    {

    lazyInterceptor.OnPropertyGetSet(this, "Name");

    dirtyInterceptor.OnPropertySet(this, this.name, value);

    base.Name = value;

    }

    }

    

    public override decimal Salary

    {

    get

    {

    lazyInterceptor.OnPropertyGetSet(this, "Salary");

    return base.Salary;

    }

    set

    {

    lazyInterceptor.OnPropertyGetSet(this, "Salary");

    dirtyInterceptor.OnPropertySet(this, this.name, value);

    base.Salary = value;

    }

    }

    

    //The ILazy interface is implemented

    //by forwarding the calls to the mixin,

    //which contains the actual implementation.

    bool ILazy.Loaded

    {

    get { return lazyMixin.Loaded; }

    set { lazyMixin.Loaded = value; }

    }

    }

    

    //The following mixin and interceptor classes

    //contain all the actual infrastructural logic

    //associated with the dirty tracking and

    //the lazy loading features.

    public class LazyMixin : ILazy

    {

    private bool loaded;

    /// 


    /// The Loaded property is "write-once" -

    /// after you have set it to true you can not set

    /// it to false again

    /// 

    bool ILazy.Loaded

    {

    get { return loaded; }

    set

    {

    if (loaded)

    return;

    

    loaded = value;

    }

    }

    }

    

    public class DirtyInterceptor

    {

    public void OnPropertySet(

    object obj,

    object oldValue,

    object newValue)

    {

    if (!oldValue.Equals(newValue))

    {

    IDirty dirty = obj as IDirty;

    if (dirty != null)

    dirty.Dirty = true;

    }

    }

    }

    

    public class LazyInterceptor

    {

    public void OnPropertyGetSet(object obj)

    {

    ILazy lazy = obj as ILazy;

    if (lazy != null)

    {

    if (!lazy.Loaded)

    {

    lazy.Loaded = true;

    

    //perform lazy loading...

    //(omitted)

    }

    }

    }

    }

通過(guò)重構(gòu)，最終所有實(shí)際的基礎(chǔ)架構(gòu)邏輯都被放進(jìn)了混入和攔截器類，代理子類變得很苗條，變成專注于轉(zhuǎn)發(fā)請(qǐng)求到攔截器和混入的輕量級(jí)類。事實(shí)上，在這一點(diǎn)上，代理子類里面除了由很容易被代碼生成工具生成的樣板代碼之外，再?zèng)]其它什么內(nèi)容。

一種選擇是在設(shè)計(jì)時(shí)生成代理子類的代碼，但是像C#和Java這樣的語(yǔ)言能讓你在運(yùn)行時(shí)生成、編譯、執(zhí)行代碼。因此，我們也可以選擇在運(yùn)行時(shí)生成代理子類，這種做法就是俗稱的運(yùn)行時(shí)子類化（runtime subclassing）。

花一點(diǎn)兒時(shí)間回頭想想我們走了多遠(yuǎn)。在第一步，我們將肥領(lǐng)域模型重構(gòu)為帶有代理子類的POJO/POCO領(lǐng)域模型（還可選擇增加一個(gè)基類），同時(shí)基礎(chǔ)架構(gòu)代碼仍然分布在領(lǐng)域模型中。在重構(gòu)的第二步，所有實(shí)際的基礎(chǔ)架構(gòu)邏輯從代理子類分離了出來(lái)，并加入到可重用的混入和攔截器類，在代理子類中只留下了樣板代碼。

在最后一步，我們轉(zhuǎn)向使用運(yùn)行時(shí)代碼生成器來(lái)為樣板代理子類生成全部代碼。就這樣我們一路跋涉到了面向方面編程的疆界。

使用面向方面編程

很長(zhǎng)一段時(shí)間，我對(duì)AOP的大肆宣傳都感到很新奇，每次我嘗試研究它是怎么一回事的時(shí)候，就會(huì)完全迷惑——這主要因?yàn)锳OP社區(qū)堅(jiān)持使用他們哪種奇怪的術(shù)語(yǔ)。而且常常有一些（不是全部！）AOP倡導(dǎo)者似乎在故意讓這個(gè)領(lǐng)域看起來(lái)那么的不同，讓人興奮并覺(jué)得膽怯。

因此，如果說(shuō)讀到這里，實(shí)際上你已經(jīng)掌握了面向方面編程的所有主要概念，你可能會(huì)感到驚訝——不但如此，而且你已經(jīng)看到了AOP框架在背后是如何運(yùn)作的，從頭到腳。

面向方面編程使用了“方面”這個(gè)核心概念，方面簡(jiǎn)單來(lái)說(shuō)是一組引介（introductions，即混入）和通知（advice，即攔截器）。方面（攔截器和混入）可以通過(guò)運(yùn)行時(shí)子類化（runtime subclassing）的方式（以及其他技術(shù)）在運(yùn)行時(shí)應(yīng)用于現(xiàn)有的類。

正如你看到的，你已經(jīng)理解了大部分怪異但重要的AOP術(shù)語(yǔ)。被大量用來(lái)描述方面對(duì)什么有益的術(shù)語(yǔ)橫切（crosscutting）關(guān)注點(diǎn)，簡(jiǎn)單意思就是你有一個(gè)能應(yīng)用于大多數(shù)（不一定屬于同一個(gè)繼承樹的）類的功能——例如我們的臟跟蹤和懶加載功能，這些功能就是橫切跨領(lǐng)域模型的關(guān)注點(diǎn)。

我們至今還未真正涵蓋、唯一真正重要的AOP術(shù)語(yǔ)是連接點(diǎn)（join point）和切點(diǎn)（pointcutting）。連接點(diǎn)是目標(biāo)類中的一個(gè)地方，你可以在那里應(yīng)用攔截器或混入。通常，攔截器所關(guān)心的連接點(diǎn)是方法，而混入所關(guān)心的連接點(diǎn)則是類本身。簡(jiǎn)單地說(shuō)，連接點(diǎn)就是你能加入方面的點(diǎn)。

為了確定哪個(gè)方面應(yīng)該被應(yīng)用到哪個(gè)連接點(diǎn)，你可以使用切點(diǎn)語(yǔ)言。這個(gè)語(yǔ)言可以很簡(jiǎn)單，可以是描述性的語(yǔ)言，比如你可能只是在一個(gè)xml文件中命名方面、命名連接點(diǎn)組合；但是也有復(fù)雜的可以使用正則表達(dá)式、甚至完整的領(lǐng)域特定語(yǔ)言（Domain Specific Languages）來(lái)進(jìn)行更高級(jí)的“切點(diǎn)“。

到目前為止，我們還尚未關(guān)注切點(diǎn)，因?yàn)槲覀円呀?jīng)在我們需要的地方手工應(yīng)用了我們的方面（我們的混入和攔截器）。但是，如果我們要想走完最后的一步，為應(yīng)用我們的方面而使用AOP框架，我們還是需要考慮這個(gè)問(wèn)題。

但在我們做之前，先讓我們停下來(lái)思索一下這個(gè)計(jì)劃。在我們前面已經(jīng)完成那么多重構(gòu)之后，現(xiàn)在加入AOP框架步子其實(shí)并不大。它僅僅是很小的一步，因?yàn)槲覀円呀?jīng)有效地重構(gòu)了我們的應(yīng)用，使其使用攔截器（通知）和混入（介紹）形式的方面。

事實(shí)上，我會(huì)認(rèn)為我們實(shí)質(zhì)上已經(jīng)在利用AOP了——我們只是還沒(méi)有用AOP框架來(lái)為我們自動(dòng)化那些例行公事的部分。但是我們利用著來(lái)自AOP的所有基本的概念（攔截和混入），并且我們用一種可重用的方式處理橫切關(guān)注點(diǎn)。這聽(tīng)起來(lái)像極了AOP的定義，所以AOP框架能幫助我們自動(dòng)化完成之前的一些手工工作是一點(diǎn)兒也不會(huì)令人感到意外的。

目前攔截器和混入類中的代碼只要輕微地修改一下就是方面了——它已經(jīng)被重構(gòu)為一個(gè)泛化的、可重用的形式，這正是方面應(yīng)該具有的形式。我們需要AOP框架做的只是以某種方式幫助我們將方面應(yīng)用到領(lǐng)域模型類中。如前所述，AOP框架有許多方式可以做到這一點(diǎn)，其中一種方式是在運(yùn)行時(shí)生成代理子類。

如果用的是運(yùn)行時(shí)子類化框架，生成的代理子類代碼看起來(lái)會(huì)和我們例子中代理子類的樣板代碼非常近似。換句話說(shuō)，它很容易生成。如果你認(rèn)為你可以寫一個(gè)代碼生成器來(lái)完成任務(wù)，那么你就在實(shí)現(xiàn)你自己的AOP框架引擎的半路上了。

重構(gòu)到方面

在我們最后的重構(gòu)中，我們將看一下，如果我們使用一個(gè)AOP框架來(lái)應(yīng)用我們的攔截器和混入，那么我們的例子代碼會(huì)怎樣。在這個(gè)例子中，我將使用NAspect，這是Roger Johansson和我合作完成的一個(gè)針對(duì).NET的開(kāi)源AOP框架。NAspect使用運(yùn)行時(shí)子類來(lái)運(yùn)用方面。

讀到這里，至今你應(yīng)該不難理解NAspect執(zhí)行的“花招”——它簡(jiǎn)單地生成包含樣板代碼的代理子類，樣板代碼需要轉(zhuǎn)發(fā)請(qǐng)求到混入和攔截器，并且它使用標(biāo)準(zhǔn)的、面向?qū)ο蟮摹㈩I(lǐng)域類成員的重寫，來(lái)提供攔截。

很多人把AOP和最糟糕的巫術(shù)聯(lián)系在一起。奇怪的術(shù)語(yǔ)已經(jīng)令人怯步，開(kāi)發(fā)人員在領(lǐng)域類代碼中預(yù)見(jiàn)不到的事情忽然并“毫無(wú)察覺(jué)”地發(fā)生在攔截器中，令很多人遭受打擊，深深地感到不安。

當(dāng)然，具體了解這些術(shù)語(yǔ)是什么意思會(huì)有幫助。能理解至少一種運(yùn)用方面的方法也是有幫助的，至少能讓你看到這不是什么魔術(shù)——只是幾個(gè)良好的、成熟的、眾所周知的、面向?qū)ο蟮脑O(shè)計(jì)模式在發(fā)揮作用。

AOP就是用我們熟知的面向?qū)ο髞?lái)對(duì)付橫切關(guān)注點(diǎn)。AOP框架只是讓你能夠更舒服地運(yùn)用方面，不用自己手寫許多代理子類。

所以，現(xiàn)在我們不會(huì)再被AOP給嚇到了，讓我們看看我們?nèi)绾问褂盟鼇?lái)使我們的應(yīng)用向終點(diǎn)線邁出最后一步。

在這個(gè)例子里，我們要做的第一件事情是包含一個(gè)對(duì)NAspect框架程序集的引用。準(zhǔn)備好之后，我們就可以開(kāi)始創(chuàng)建我們的方面、確定我們的切點(diǎn)。我們也可以直接刪除PersonProxy和EmployeeProxy類——從現(xiàn)在開(kāi)始，NAspect會(huì)為我們生成這些類。

如果我們?cè)敢猓覀兩踔量梢詣h除DomainBase基類——沒(méi)有必要使用基類來(lái)應(yīng)用公用于所有基類的混入，我們也可以使用AOP框架來(lái)做這些。這意味著，通過(guò)使用AOP框架，我們甚至可以無(wú)需任何額外工作就能滿足POJO/POCO的嚴(yán)格要求。

為了除去基類，我們只需要把功能移到混入中去。就我們的情況而言，我們僅需要再創(chuàng)建一個(gè)混入——DirtyMixin，它持有先前放在基類中的臟標(biāo)記。

LazyMixin類中的代碼完全保持不變，所以這里不再列出。實(shí)際上，我們真正需要去做的是創(chuàng)建新的DirtyMixin類，并稍微修改兩個(gè)攔截器中的代碼，讓它們使用NAspect傳進(jìn)來(lái)的描述被攔截方法的數(shù)據(jù)結(jié)構(gòu)。

我們還需要修改我們的工廠類，以便它使用NAspect來(lái)為我們創(chuàng)建代理子類。這假定我們已經(jīng)在應(yīng)用中的所有地方都轉(zhuǎn)為使用抽象工廠模式。如果我們還沒(méi)有這樣做，現(xiàn)在我們一定要汲取教訓(xùn)，因?yàn)闆](méi)有抽象工廠模式，我們將不得不進(jìn)行另一項(xiàng)龐大的搜索、替換操作，仔細(xì)檢查代碼中每一個(gè)代理子類被實(shí)例化的地方，改為調(diào)用NAspect運(yùn)行時(shí)子類化引擎。

重構(gòu)后的代碼如清單6所示，準(zhǔn)備好使用NAspect。

public class DirtyMixin : IDirty

    {

    private bool dirty;

    bool IDirty.Dirty

    {

    get { return dirty; }

    set { dirty = value; }

    }

    }

    

    public class DirtyInterceptor : IAroundInterceptor

    {

    public object HandleCall(MethodInvocation call)

    {

    IDirty dirty = call.Target as IDirty;

    

    if (dirty != null)

    {

    //Extract the new value from the call object

    object newValue = call.Parameters[0].Value;

    

    //Extract the current value using reflection

    object value = call.Target.GetType().GetProperty(

    call.Method.Name.Substring(4)).GetValue(

    call.Target, null);

    

    //Mark as dirty if the new value is

    //different from the old value

    if (!value.Equals(newValue))

    dirty.Dirty = true;

    }

    

    return call.Proceed();

    }

    }

    

    public class LazyInterceptor : IAroundInterceptor

    {

    public object HandleCall(MethodInvocation call)

    {

    ILazy lazy = call.Target as ILazy;

    

    if (lazy != null)

    {

    if (!lazy.Loaded)

    {

    lazy.Loaded = true;

    

    //perform lazy loading...

    //(omitted)

    }

    }

    

    return call.Proceed();

    }

    }

    

    public class Factory

    {

    public static IEngine engine = ApplicationContext.Configure();

    

    public static Domain.Person CreatePerson()

    {         return engine.CreateProxyPerson>();

    }

    

    public static Domain.Employee CreateEmployee()

    {

    return engine.CreateProxyEmployee>();

    }

    }

為了知道你的方面要應(yīng)用到哪個(gè)類，NAspect在程序的配置文件中使用一個(gè)xml配置段（也有其它選擇）。現(xiàn)在我們可以在xml文件中定義方面，指出混入和攔截器類的類型，以及我們想應(yīng)用的類型。大體上，我們準(zhǔn)備好了嘗試一下我們的AOP應(yīng)用。

不過(guò)，仍然有一點(diǎn)讓許多開(kāi)發(fā)人員對(duì)使用AOP猶豫不決，甚至當(dāng)他們理解了AOP的術(shù)語(yǔ)和理論，那就是由于切點(diǎn)體系定義得不完善而帶來(lái)的脆弱性。

雖然我們通過(guò)一些巧妙的正則表達(dá)式來(lái)篩選出打算應(yīng)用方面的類和成員，但風(fēng)險(xiǎn)是當(dāng)領(lǐng)域模型變化的時(shí)候，你可能會(huì)忘了更新切點(diǎn)定義，以致正則表達(dá)式忽然篩選到了不應(yīng)該應(yīng)用方面的類。就是這類問(wèn)題給AOP帶來(lái)了巫術(shù)的壞名聲。

處理切點(diǎn)不明確的一個(gè)方式是創(chuàng)建自定義的.NET屬性（Attribute）（Java中的注釋（annotations））。用自定義屬性裝飾領(lǐng)域模型，然后使用屬性做為切點(diǎn)目標(biāo)，這樣就可以避免使用正則表達(dá)式之類的小花招。方面只應(yīng)用于我們決定該應(yīng)用的地方，通過(guò)在那里放置屬性。

因此根據(jù)我們的情況，我們繼續(xù)創(chuàng)建兩個(gè)自定義屬性——LazyAttribute和DirtyAttribute——接下來(lái)我們使用它們來(lái)裝飾我們的類（清單7）。

public class DirtyAttribute : Attribute

    {

    }

    

    public class LazyAttribute : Attribute

    {

    }

    

    [Dirty]

    public class Person : DomainBase

    {

    protected string name;

    public virtual string Name

    {

    get { return name; }

    [Dirty]

    set { name = value; }

    }

    }

    

    [Dirty]

    [Lazy]

    public class Employee : Person

    {

    protected decimal salary;

    public virtual decimal Salary

    {

    [Lazy]

    get { return salary; }

    [Dirty]

    [Lazy]

    set { salary = value; }

    }

    

    public override string Name

    {

    [Lazy]

    get { return name; }

    [Dirty]

    [Lazy]

    set { name = value; }

    }

    }

我們接著在應(yīng)用的配置文件中定義我們的切點(diǎn)（清單8），讓方面以我們自定義的屬性為目標(biāo)。

    

    

    

    
 name="naspect" 

    type="Puzzle.NAspect.Framework.Configuration.NAspectConfigurationHandler, Puzzle.NAspect.Framework.NET2"/>

    

    

    

    

    

    

    

    name="DirtyAspect"

    target-attribute="InfoQ.AspectsOfDMM.Attributes.DirtyAttribute, InfoQ.AspectsOfDMM" >

    

    target-attribute="InfoQ.AspectsOfDMM.Attributes.DirtyAttribute, InfoQ.AspectsOfDMM" >

    

    type="InfoQ.AspectsOfDMM.Aspects.DirtyInterceptor, InfoQ.AspectsOfDMM" />

    

    

    

    

    

    

    

    name="LazyAspect"

    target-attribute="InfoQ.AspectsOfDMM.Attributes.LazyAttribute, InfoQ.AspectsOfDMM" >

    

    target-attribute="InfoQ.AspectsOfDMM.Attributes.LazyAttribute, InfoQ.AspectsOfDMM" >

    

    type="InfoQ.AspectsOfDMM.Aspects.LazyInterceptor, InfoQ.AspectsOfDMM" />

    

    

    

    

    

    

    

    

    

    

現(xiàn)在，我們最后測(cè)試一下我們的AOP應(yīng)用。當(dāng)我們運(yùn)行應(yīng)用時(shí)，NAspect會(huì)在運(yùn)行時(shí)為我們生成代理子類，并在子類中插入樣板代碼來(lái)將所有的請(qǐng)求轉(zhuǎn)發(fā)到攔截器和混入類。

程序最后的架構(gòu)可參看圖12。注意，這個(gè)版本和先前非AOP版本之間的唯一實(shí)際差別是，兩個(gè)代理類（使用虛線邊框標(biāo)識(shí)）將由AOP框架生成，而之前我們必須手工編碼。

與圖11比較，我們多了一個(gè)DirtyTrackerMixin類和一個(gè)新的IDirtyTracker接口，來(lái)代替DomainBase基類，但這些東西哪怕我們不使用AOP，只要決定不使用公共基礎(chǔ)架構(gòu)基類（以滿足更嚴(yán)格的POJO/POCO需求）就是要有的。換句話說(shuō)，如果我們不想使用一個(gè)公共基類，不管我們是否使用AOP框架，我們最終都會(huì)得到一樣的架構(gòu)（圖12所示）。

切點(diǎn)選項(xiàng)

當(dāng)你添加新的領(lǐng)域模型類時(shí)，要想使它們能夠懶加載和臟跟蹤，只需要用自定義屬性裝飾它們，就會(huì)”變魔術(shù)一樣地“獲得相應(yīng)功能了。

用屬性/注釋來(lái)作為切點(diǎn)目標(biāo)，很快你就會(huì)注意到，由于每項(xiàng)功能對(duì)應(yīng)一個(gè)屬性，很快領(lǐng)域模型中每個(gè)成員的屬性就太多了。因此，為了減少屬性的數(shù)量，你可能想找到它們之間的抽象性。

如果你適應(yīng)基于正則表達(dá)式的切點(diǎn)方法，并且你覺(jué)得屬性令領(lǐng)域模型變得雜亂，使得保持領(lǐng)域模型與基礎(chǔ)架構(gòu)關(guān)注點(diǎn)完全無(wú)關(guān)的目標(biāo)受到了損害，那么另一種選擇是，你可以只配置你的xml配置文件來(lái)匹配相關(guān)的目標(biāo)類，并且不需要用自定義屬性裝飾你的領(lǐng)域類。

另外，NAspect的xml切點(diǎn)語(yǔ)言（像許多其它的AOP框架一樣）允許你簡(jiǎn)單地提供一個(gè)完整的類型清單，方面會(huì)運(yùn)用于列出的類型，讓你不用去找到一個(gè)剛好只匹配正確類的正則表達(dá)式。這使配置文件變得更長(zhǎng)，但是能讓你的領(lǐng)域模型保持完全干凈。

在使用切點(diǎn)來(lái)動(dòng)態(tài)運(yùn)用方面的地方使用AOP框架，還有一個(gè)好處就是，當(dāng)方面被用在不同的用例中時(shí)，把不同的方面應(yīng)用于相同的類中會(huì)變得很容易。如果一個(gè)用例要求某個(gè)領(lǐng)域類懶加載，而另一個(gè)用例不需要，那么只有第一個(gè)用例需要使用應(yīng)用懶加載方面的配置文件。

這個(gè)動(dòng)態(tài)的方面應(yīng)用可以非常強(qiáng)大，比如在測(cè)試場(chǎng)景可以額外應(yīng)用一些測(cè)試用的方面，提供mocking之類的功能。

使用面向方面編程的結(jié)論

我們是否可以在領(lǐng)域模型中放置任何基礎(chǔ)架構(gòu)代碼，這是我們開(kāi)始時(shí)的問(wèn)題。我們看到，這絕對(duì)可取，因?yàn)樗钤S多功能得以更有效率地實(shí)現(xiàn)，但是可能使我們的領(lǐng)域模型變得“肥胖”。

為了解決這個(gè)問(wèn)題，我們重構(gòu)了我們的肥領(lǐng)域模型——首先是把基礎(chǔ)架構(gòu)代碼移到代理子類和一個(gè)基類中，然后將實(shí)際的邏輯從代理子類中移出、移到混入和攔截器類中。這使我們的領(lǐng)域模型變得更漂亮，但是在代理子類中最終卻有很多樣板代碼需要寫。為了解決這個(gè)問(wèn)題，我們轉(zhuǎn)向了面向方面編程。

結(jié)果發(fā)現(xiàn)邁向AOP框架的步子原來(lái)是如此之小——事實(shí)上應(yīng)用的架構(gòu)并沒(méi)有任何改變——以至它大概使一些讀者感到驚奇，這些讀者甚至有熟悉的感覺(jué)，這種感覺(jué)就像當(dāng)你第一次理解一個(gè)設(shè)計(jì)模式時(shí)，你意識(shí)到它就是你已經(jīng)用了很多次的東西，只是不知道它有一個(gè)這樣的名字。

你很可能在許多應(yīng)用中有效地使用過(guò)AOP，但并沒(méi)認(rèn)識(shí)到它是AOP，并且好像沒(méi)有使用過(guò)AOP框架來(lái)幫助你自動(dòng)化地生成部分樣板代碼。

我們現(xiàn)在在這篇文章的結(jié)尾處，很希望在這個(gè)地方你會(huì)同意我的看法：

它實(shí)際上就是一個(gè)通過(guò)使用良好的、成熟的面向?qū)ο竽Ｊ剑€(wěn)步提高應(yīng)用架構(gòu)的重構(gòu)問(wèn)題。這樣做的時(shí)候，不要害怕走向一個(gè)使用代理來(lái)運(yùn)用攔截器和混入的，可稱為面向方面的應(yīng)用架構(gòu)。

不管你是否進(jìn)一步讓一個(gè)AOP框架來(lái)幫助你應(yīng)用方面，這都不會(huì)真正影響你是否在進(jìn)行AOP。因?yàn)椋绻闶琼樦@篇文章討論的路線來(lái)重構(gòu)你的應(yīng)用的，你就是在進(jìn)行AOP——不管有沒(méi)有一個(gè)框架的幫助。

摘要

通過(guò)使用像代理模式、抽象工廠模式、組合模式這些傳統(tǒng)的、知名的面向?qū)ο笤O(shè)計(jì)模式來(lái)重構(gòu)我們的肥領(lǐng)域模型，我們得到了一個(gè)極好地結(jié)合了精益領(lǐng)域模型和基礎(chǔ)架構(gòu)的應(yīng)用架構(gòu)，基礎(chǔ)架構(gòu)充分利用了面向?qū)ο蟮母拍詈蜆?gòu)造。這樣，我們巧妙地避免陷入肥領(lǐng)域模型和貧血領(lǐng)域模型反模式的陷阱。

使用這篇文章中討論的模式，得到了一個(gè)可以被形容為面向方面的應(yīng)用架構(gòu)。這是因?yàn)槲覀冏罱K用混入和攔截器類解決了橫切關(guān)注點(diǎn)，混入和攔截器則精密地與面向方面編程中的介紹和通知匹配了起來(lái)。

如果你想親自體驗(yàn)使用AOP是不是真的那么輕松愉快，而且不介意使用不是親手鍵入的代碼，你可以下載本文隨附的Visual Studio 2005工程的所有代碼。

總之，在這篇文章中，我嘗試去展示面向方面的概念和工具是怎樣提供一個(gè)偉大的方式去看待和運(yùn)用許多領(lǐng)域模型管理關(guān)注點(diǎn)，以及它們是如何大大減輕了肥領(lǐng)域模型反模式的風(fēng)險(xiǎn)。

關(guān)于作者

Mats Helander是Avanade（荷蘭）的一位資深軟件開(kāi)發(fā)咨詢師。業(yè)余時(shí)間，他和Roger Johansson一起開(kāi)發(fā)了免費(fèi)的Puzzle.NET套件，Puzzle.NET是一個(gè)開(kāi)源框架和工具。Puzzle.NET包括NPersist、ObjectMapper（對(duì)象/關(guān)系映射）、NAspect（面向方面編程）、NFactory（依賴注入）、以及NPath（內(nèi)存對(duì)象查詢）。