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

因此到目前為止我們已經整理出了一個架構，能讓我們把完全POJO/POCO的領域模型類和將基礎架構代碼分布到領域模型中去的目標結合在一起。如果我們的目標僅僅是避免肥領域模型，而不強求符合POJO/POCO定義，那么我們就能走“半POJO/POCO”的路線，用一個公共基類來節省一些工作。

使用抽象工廠模式

這聽起來很棒，對不對？你可能在想，用它是不是沒有任何問題呢。軟件業的人都有些吹毛求疵，你大概已經在疑心有那么一兩個棘手問題該冒頭了吧。

你是對的。有兩件值得關注的事情馬上就自己顯現出來了。第一個相當輕微：為了讓子類能夠重寫領域模型類的成員，并提供攔截，所有的領域模型成員（或至少打算攔截的那些成員）必須是虛擬的。

第二個問題好像更為糟糕一些：既然你想讓你的程序使用代理子類的實例，你必須在應用代碼中查找所有創建領域模型類實例的地方，將它們改成創建相應的代理子類的實例。

要修改已存在的應用，聽起來像個噩夢吧？沒錯。要想避免這種大規模的查找和替換操作，只有一條出路，就是從一開始就避免使用“new”關鍵字來創建領域模型類的實例。

避免"new"的傳統方法就是使用抽象工廠模式[GoF設計模式]。調用一個工廠類的Create()方法，而不是任由客戶代碼使用“new”來創建實例。Create()方法負責調用“new”，并且在返回新的實例之前會對其做一些額外的相關設置操作。

如果你在調用領域模型的時候全都使用抽象工廠模式，那就最好不過了，接下來你只要在代碼中改一個地方——工廠類——將返回領域類實例改為返回代理子類（或者是基于接口的代理）的實例。

這是使用抽象工廠模式來實例化所有的領域對象的一個重要理由——至少使用像Java和C#這樣的語言時是這樣，這些語言不允許奇異特性，比如不能像C++一樣重載（overload）成員取用運算子，不能像ObjectiveC一樣改變“new”關鍵字的行為，也不能像Ruby一樣在運行時修改類。

繼承反射

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

如果你看一下圖9，你會發現Employee繼承Person類，這是應該的：無論什么時候，如果一個方法期望Person對象，那么傳遞給它Employee對象應該也能工作。此外，PersonProxy類繼承Person類。這也很好，因為這意味著將一個PersonProxy對象作為參數傳遞給期望Person對象的方法也是“合法的”。

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

所有一切都符合我們的期望。當我們讓抽象工廠開始返回代理對象而不是領域模型類的簡單實例時，有一點是很重要的，我們希望客戶端代碼仍然繼續正常運行，而無需重新考慮如何處理我們的類型層次。

換句話說，如果我們原來向一個期望Person對象的方法傳遞Employee對象給，當我們忽然換成給它傳遞EmployeeProxy對象的時候，我們的代碼必須還能正常編譯（并且工作）。幸運的是，由于EmployeeProxy繼承Employee，并且Employee繼承Person，所以沒有問題。

事實上，當開始使用代理來代替領域模型對象時，一切都將如常繼續運轉，正如我們希望的。只不過，有一個個非常微小的例外。

圖9中的紅色繼承線表示EmployeeProxy不繼承PersonProxy。這什么時候會帶來問題呢？

好，考慮一下這樣一個方法，它接受兩個對象，并用反射來確定其中一種對象是否是另一種對象的子類。當我們把一個Person對象和一個Employee對象傳遞給該方法時，它會返回true。但是當我們把一個PersonProxy對象和一個EmployeeProxy對象傳遞給該方法時，突然它就返回false了。

除非你有基于反射的、檢查繼承層次的代碼，不然應該是安全的。但是萬一你真的有這樣的代碼，這里先警告一下也沒壞處（你可以通過修改反射代碼來避開這個問題，讓它檢測代理類型，并一路向上直到找到一個非代理類型）。

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

我們已經向著可維護的領域模型架構努力了很長時間，讓它能容下一個有效率的、可訪問的基礎架構來實行運行時領域模型管理。

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

讓我們開始看一下那些只針對某些領域類、而不是全部領域類的功能——對于這些功能，我們需要將所需的基礎架構成員放在代理子類中，而不是在公用的基類中。在我們的例子中，為懶加載功能設置的加載標記將必須添加到需要支持懶加載的每個類的子類中。

由于我們可能需要在多個子類中放相同的代碼，所以我們明顯會導致代碼重復。只有一個標記的時候情況還好，但是對于需要多個屬性、甚至需要多個有復雜實現的方法的功能呢？

在我們的例子中，加載標記是一次寫入（write-once），所以在變成true之后不能再切換回來。因此，在setter方法中，我們有一些代碼來實施這個規則——在需要懶加載的每個領域模型類的子類中，我們都要在setter方法中重復的那些代碼。

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

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

有一點可以補充說明一下，使用我們這種組合方式，以混入的形式存在的行為和狀態能動態地被加到目標類中（使用依賴注入），而不是靜態地綁定到目標上去（如果行為是繼承下來的就會如此）。盡管在這篇文章中我們不會更多關注于如何利用它的潛能，但是它為支持一些非常靈活和動態的場景提供了非常大的空間。

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

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

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

//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)

    }

    }

    }

    }

通過重構，最終所有實際的基礎架構邏輯都被放進了混入和攔截器類，代理子類變得很苗條，變成專注于轉發請求到攔截器和混入的輕量級類。事實上，在這一點上，代理子類里面除了由很容易被代碼生成工具生成的樣板代碼之外，再沒其它什么內容。

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

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

在最后一步，我們轉向使用運行時代碼生成器來為樣板代理子類生成全部代碼。就這樣我們一路跋涉到了面向方面編程的疆界。

使用面向方面編程

很長一段時間，我對AOP的大肆宣傳都感到很新奇，每次我嘗試研究它是怎么一回事的時候，就會完全迷惑——這主要因為AOP社區堅持使用他們哪種奇怪的術語。而且常常有一些（不是全部！）AOP倡導者似乎在故意讓這個領域看起來那么的不同，讓人興奮并覺得膽怯。

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

面向方面編程使用了“方面”這個核心概念，方面簡單來說是一組引介（introductions，即混入）和通知（advice，即攔截器）。方面（攔截器和混入）可以通過運行時子類化（runtime subclassing）的方式（以及其他技術）在運行時應用于現有的類。

正如你看到的，你已經理解了大部分怪異但重要的AOP術語。被大量用來描述方面對什么有益的術語橫切（crosscutting）關注點，簡單意思就是你有一個能應用于大多數（不一定屬于同一個繼承樹的）類的功能——例如我們的臟跟蹤和懶加載功能，這些功能就是橫切跨領域模型的關注點。

我們至今還未真正涵蓋、唯一真正重要的AOP術語是連接點（join point）和切點（pointcutting）。連接點是目標類中的一個地方，你可以在那里應用攔截器或混入。通常，攔截器所關心的連接點是方法，而混入所關心的連接點則是類本身。簡單地說，連接點就是你能加入方面的點。

為了確定哪個方面應該被應用到哪個連接點，你可以使用切點語言。這個語言可以很簡單，可以是描述性的語言，比如你可能只是在一個xml文件中命名方面、命名連接點組合；但是也有復雜的可以使用正則表達式、甚至完整的領域特定語言（Domain Specific Languages）來進行更高級的“切點“。

到目前為止，我們還尚未關注切點，因為我們已經在我們需要的地方手工應用了我們的方面（我們的混入和攔截器）。但是，如果我們要想走完最后的一步，為應用我們的方面而使用AOP框架，我們還是需要考慮這個問題。

但在我們做之前，先讓我們停下來思索一下這個計劃。在我們前面已經完成那么多重構之后，現在加入AOP框架步子其實并不大。它僅僅是很小的一步，因為我們已經有效地重構了我們的應用，使其使用攔截器（通知）和混入（介紹）形式的方面。

事實上，我會認為我們實質上已經在利用AOP了——我們只是還沒有用AOP框架來為我們自動化那些例行公事的部分。但是我們利用著來自AOP的所有基本的概念（攔截和混入），并且我們用一種可重用的方式處理橫切關注點。這聽起來像極了AOP的定義，所以AOP框架能幫助我們自動化完成之前的一些手工工作是一點兒也不會令人感到意外的。

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

如果用的是運行時子類化框架，生成的代理子類代碼看起來會和我們例子中代理子類的樣板代碼非常近似。換句話說，它很容易生成。如果你認為你可以寫一個代碼生成器來完成任務，那么你就在實現你自己的AOP框架引擎的半路上了。

重構到方面

在我們最后的重構中，我們將看一下，如果我們使用一個AOP框架來應用我們的攔截器和混入，那么我們的例子代碼會怎樣。在這個例子中，我將使用NAspect，這是Roger Johansson和我合作完成的一個針對.NET的開源AOP框架。NAspect使用運行時子類來運用方面。

讀到這里，至今你應該不難理解NAspect執行的“花招”——它簡單地生成包含樣板代碼的代理子類，樣板代碼需要轉發請求到混入和攔截器，并且它使用標準的、面向對象的、領域類成員的重寫，來提供攔截。

很多人把AOP和最糟糕的巫術聯系在一起。奇怪的術語已經令人怯步，開發人員在領域類代碼中預見不到的事情忽然并“毫無察覺”地發生在攔截器中，令很多人遭受打擊，深深地感到不安。

當然，具體了解這些術語是什么意思會有幫助。能理解至少一種運用方面的方法也是有幫助的，至少能讓你看到這不是什么魔術——只是幾個良好的、成熟的、眾所周知的、面向對象的設計模式在發揮作用。

AOP就是用我們熟知的面向對象來對付橫切關注點。AOP框架只是讓你能夠更舒服地運用方面，不用自己手寫許多代理子類。

所以，現在我們不會再被AOP給嚇到了，讓我們看看我們如何使用它來使我們的應用向終點線邁出最后一步。

在這個例子里，我們要做的第一件事情是包含一個對NAspect框架程序集的引用。準備好之后，我們就可以開始創建我們的方面、確定我們的切點。我們也可以直接刪除PersonProxy和EmployeeProxy類——從現在開始，NAspect會為我們生成這些類。

如果我們愿意，我們甚至可以刪除DomainBase基類——沒有必要使用基類來應用公用于所有基類的混入，我們也可以使用AOP框架來做這些。這意味著，通過使用AOP框架，我們甚至可以無需任何額外工作就能滿足POJO/POCO的嚴格要求。

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

LazyMixin類中的代碼完全保持不變，所以這里不再列出。實際上，我們真正需要去做的是創建新的DirtyMixin類，并稍微修改兩個攔截器中的代碼，讓它們使用NAspect傳進來的描述被攔截方法的數據結構。

我們還需要修改我們的工廠類，以便它使用NAspect來為我們創建代理子類。這假定我們已經在應用中的所有地方都轉為使用抽象工廠模式。如果我們還沒有這樣做，現在我們一定要汲取教訓，因為沒有抽象工廠模式，我們將不得不進行另一項龐大的搜索、替換操作，仔細檢查代碼中每一個代理子類被實例化的地方，改為調用NAspect運行時子類化引擎。

重構后的代碼如清單6所示，準備好使用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>();

    }

    }

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

不過，仍然有一點讓許多開發人員對使用AOP猶豫不決，甚至當他們理解了AOP的術語和理論，那就是由于切點體系定義得不完善而帶來的脆弱性。

雖然我們通過一些巧妙的正則表達式來篩選出打算應用方面的類和成員，但風險是當領域模型變化的時候，你可能會忘了更新切點定義，以致正則表達式忽然篩選到了不應該應用方面的類。就是這類問題給AOP帶來了巫術的壞名聲。

處理切點不明確的一個方式是創建自定義的.NET屬性（Attribute）（Java中的注釋（annotations））。用自定義屬性裝飾領域模型，然后使用屬性做為切點目標，這樣就可以避免使用正則表達式之類的小花招。方面只應用于我們決定該應用的地方，通過在那里放置屬性。

因此根據我們的情況，我們繼續創建兩個自定義屬性——LazyAttribute和DirtyAttribute——接下來我們使用它們來裝飾我們的類（清單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; }

    }

    }

我們接著在應用的配置文件中定義我們的切點（清單8），讓方面以我們自定義的屬性為目標。

    

    

    

    
 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" />

    

    

    

    

    

    

    

    

    

    

現在，我們最后測試一下我們的AOP應用。當我們運行應用時，NAspect會在運行時為我們生成代理子類，并在子類中插入樣板代碼來將所有的請求轉發到攔截器和混入類。

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

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

切點選項

當你添加新的領域模型類時，要想使它們能夠懶加載和臟跟蹤，只需要用自定義屬性裝飾它們，就會”變魔術一樣地“獲得相應功能了。

用屬性/注釋來作為切點目標，很快你就會注意到，由于每項功能對應一個屬性，很快領域模型中每個成員的屬性就太多了。因此，為了減少屬性的數量，你可能想找到它們之間的抽象性。

如果你適應基于正則表達式的切點方法，并且你覺得屬性令領域模型變得雜亂，使得保持領域模型與基礎架構關注點完全無關的目標受到了損害，那么另一種選擇是，你可以只配置你的xml配置文件來匹配相關的目標類，并且不需要用自定義屬性裝飾你的領域類。

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

在使用切點來動態運用方面的地方使用AOP框架，還有一個好處就是，當方面被用在不同的用例中時，把不同的方面應用于相同的類中會變得很容易。如果一個用例要求某個領域類懶加載，而另一個用例不需要，那么只有第一個用例需要使用應用懶加載方面的配置文件。

這個動態的方面應用可以非常強大，比如在測試場景可以額外應用一些測試用的方面，提供mocking之類的功能。

使用面向方面編程的結論

我們是否可以在領域模型中放置任何基礎架構代碼，這是我們開始時的問題。我們看到，這絕對可取，因為它令許多功能得以更有效率地實現，但是可能使我們的領域模型變得“肥胖”。

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

結果發現邁向AOP框架的步子原來是如此之小——事實上應用的架構并沒有任何改變——以至它大概使一些讀者感到驚奇，這些讀者甚至有熟悉的感覺，這種感覺就像當你第一次理解一個設計模式時，你意識到它就是你已經用了很多次的東西，只是不知道它有一個這樣的名字。

你很可能在許多應用中有效地使用過AOP，但并沒認識到它是AOP，并且好像沒有使用過AOP框架來幫助你自動化地生成部分樣板代碼。

我們現在在這篇文章的結尾處，很希望在這個地方你會同意我的看法：

它實際上就是一個通過使用良好的、成熟的面向對象模式，穩步提高應用架構的重構問題。這樣做的時候，不要害怕走向一個使用代理來運用攔截器和混入的，可稱為面向方面的應用架構。

不管你是否進一步讓一個AOP框架來幫助你應用方面，這都不會真正影響你是否在進行AOP。因為，如果你是順著這篇文章討論的路線來重構你的應用的，你就是在進行AOP——不管有沒有一個框架的幫助。

摘要

通過使用像代理模式、抽象工廠模式、組合模式這些傳統的、知名的面向對象設計模式來重構我們的肥領域模型，我們得到了一個極好地結合了精益領域模型和基礎架構的應用架構，基礎架構充分利用了面向對象的概念和構造。這樣，我們巧妙地避免陷入肥領域模型和貧血領域模型反模式的陷阱。

使用這篇文章中討論的模式，得到了一個可以被形容為面向方面的應用架構。這是因為我們最終用混入和攔截器類解決了橫切關注點，混入和攔截器則精密地與面向方面編程中的介紹和通知匹配了起來。

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

總之，在這篇文章中，我嘗試去展示面向方面的概念和工具是怎樣提供一個偉大的方式去看待和運用許多領域模型管理關注點，以及它們是如何大大減輕了肥領域模型反模式的風險。

關于作者

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