AOP技术研究 再续
第四部分? .Net平臺AOP技術研究
4.1.Net平臺AOP技術概覽
.Net平臺與Java平臺相比，由于它至今在服務端仍不具備與unix系統的兼容性，也不具備類似于Java平臺下J2EE這樣的企業級容器，使 得.Net平臺在大型的企業級應用上，常常為人所詬病。就目前而言，.Net平臺并沒有提供AOP技術的直接實現，而微軟在未來對于.Net的發展戰略目 標，我們仍未可知。但我相信微軟對于目前炙手可熱的AOP技術應該不會視而不見。也許在未來的.Net平臺下，會出現類似于Spring那樣的輕量級 IoC容器，加上O/R Mapping的進一步實現與完善，隨著Windows Server操作系統的逐步推新，.Net平臺對于企業級系統開發的支持會越來越多。
AOP技術在.Net平臺中的應用，相較于Java平臺而言，還遠不夠成熟，功能也相對較弱，目前能夠投入商用的AOP工具幾乎沒有。借鑒Java 開源社區的成功，.Net平臺下AOP工具的開發也都依托于開源社區的力量。眾多開源愛好者，仍然在堅持不懈對AOP技術進行研究和實踐，試圖找到AOP 技術與.Net之間的完美結合點，從而開發出真正能夠商用的功能強大的AOP工具。就目前而言，大部分在.Net平臺下的AOP工具，大部分均脫胎于 Java平臺下的AOP工具，例如Spring.Net之于Spring，Eos之于AspectJ。由于Java平臺和.Net平臺在語言機制上的相似 性，使得它們在實現AOP的技術機制上，大體相似，無非是利用靜態織入或動態織入的方式，完成對aspect的實現。
目前在.Net平臺下的AOP大部分仍然處于最初的開發階段，各自發布的版本基本都是beta版。其中較有代表性的AOP工具包括Aspect#，Spring.Net，Eos等。
Aspect#是基于Castle動態代理技術實現的。Castle動態代理技術利用了.Net的Emit技術，生成一個新的類去實現特定的接口， 或者擴展一個已有的類，并將其委托指向IInterceptor接口的實現類。通過Castle動態代理技術，就可以攔截方法的調用，并將Aspect的 業務邏輯織入到方法中。利用Castle動態代理技術，最大的缺陷是它只對虛方法有效，這限制了Aspect#的一部分應用。
Spring.Net從根本意義上來說，是對Spring工具從Java平臺向.Net平臺的完全移植。它在AOP的實現上與Spring幾乎完全相似，仍然利用了AOP聯盟提供的＊＊＊、Advice等實現AOP。Spring.Net的配置文件也與Spring相同。
Eos采用的是靜態織入的技術。它提供了獨有的編譯器，同時還擴展了C#語法，以類似于AspectJ的結構，規定了一套完整的AOP語法，諸如 aspect，advice，before，after，pointcut等。Eos充分的利用了.Net中元數據的特點，以IL級的代碼對方面進行織 入，這也使得它的性能與其他AOP工具比較有較大的提高。
4.2 .Net平臺下實現AOP的技術基礎
如前所述，在.Net平臺下實現AOP，采用的方式主要是靜態織入和動態織入的方式。在本文中，我將充分利用.Net的技術特性，包括元數據、 Attribute、.Net Remoting的代理技術，將其綜合運用，最終以動態織入的方式實現AOP公共類庫。本節將介紹實現AOP所必需的.Net知識。
4.2.1元數據（metadata）
4.2.1.1元數據概述
元數據是一種二進制信息，用以對存儲在公共語言運行庫（CLR）中可移植可執行文件 (PE) 或存儲在內存中的程序進行描述。在.Net中，如果將代碼編譯為 PE 文件時，便會將元數據插入到該文件的一部分中，而該代碼被編譯成的Microsoft 中間語言 (MSIL)，則被插入到該文件的另一部分中。在模塊或程序集中定義和引用的每個類型和成員都將在元數據中進行說明。執行代碼時，運行庫將元數據加載到內 存中，并引用它來發現有關代碼的類、成員、繼承等信息。
元數據以非特定語言的方式描述在代碼中定義的每一類型和成員。它存儲的信息包括程序集的信息，如程序集的版本、名稱、區域性和公鑰，以及該程序集所 依賴的其他程序集；此外，它還包括類型的說明，包括類型的基類和實現的接口，類型成員（方法、字段、屬性、事件、嵌套的類型）。
在.Net Framework中，元數據是關鍵，該模型不再需要接口定義語言 (IDL) 文件、頭文件或任何外部組件引用方法。元數據允許 .NET 語言自動以非特定語言的方式對其自身進行描述，此外，通過使用Attribute，可以對元數據進行擴展。元數據具有以下主要優點：
1. 自描述文件
公共語言運行庫（CLR）模塊和程序集是自描述的。模塊的元數據包含與另一個模塊進行交互所需的全部信息。元數據自動提供COM中IDL的功能，允 許將一個文件同時用于定義和實現。運行庫模塊和程序集甚至不需要向操作系統注冊。運行庫使用的說明始終反映編譯文件中的實際代碼，從而提高應用程序的可靠 性。
2．語言互用性和更簡單的基于組件的設計
元數據提供所有必需的有關已編譯代碼的信息，以供您從用不同語言編寫的 PE 文件中繼承類。您可以創建用任何托管語言（任何面向公共語言運行庫的語言）編寫的任何類的實例，而不用擔心顯式封送處理或使用自定義的互用代碼。
3．Attribute
.NET Framework允許在編譯文件中聲明特定種類的元數據（稱為Attribute）。在整個 .NET Framework 中到處都可以發現Attribute的存在，Attribute用于更精確地控制運行時程序如何工作。另外，用戶可以通過自定義屬性向 .NET Framework 文件發出用戶自己的自定義元數據。
4.2.1.2元數據的結構
在PE文件中與元數據有關的主要包括兩部分。一部分是元數據，它包含一系列的表和堆數據結構。每個元數據表都保留有關程序元素的信息。例如，一個元 數據表說明代碼中的類，另一個元數據表說明字段等。如果您的代碼中有10個類，類表將有10行，每行為1個類。元數據表引用其他的表和堆。例如，類的元數 據表引用方法表。元數據以四種堆結構存儲信息：字符串、Blob、用戶字符串和 GUID。所有用于對類型和成員進行命名的字符串都存儲在字符串堆中。例如，方法表不直接存儲特定方法的名稱，而是指向存儲在字符串堆中的方法的名稱。
另一部分是MSIL指令，許多MSIL指令都帶有元數據標記。元數據標記在 PE 文件的 MSIL 部分中唯一確定每個元數據表的每一行。元數據標記在概念上和指針相似，永久駐留在MSIL中，引用特定的元數據表。元數據標記是一個四個字節的數字。最高 位字節表示特定標記（方法、類型等）引用的元數據表。剩下的三個字節指定與所說明的編程元素對應的元數據表中的行。如果用C#定義一個方法并將其編譯到 PE文件中，下面的元數據標記可能存在于PE文件的MSIL部分：
0x06000004
最高位字節 (0x06) 表示這是一個MethodDef標記。低位的三個字節 (000004) 指示公共語言運行庫在 MethodDef 表的第四行查找對該方法定義進行描述的信息。
表4.1 描述了PE文件中元數據的結構及其每部分的內容：
| PE部分 ? ? ? | PE部分的內容 ? ? ? |
表4.1? PE文件中的元數據
4.2.1.3元數據在運行時的作用
由于在MSIL指令中包含了元數據標記，因此，當公共語言運行庫（CLR）將代碼加載到內存時，將向元 數據咨詢該代碼模塊中包含的信息。運行庫對Microsoft 中間語言 (MSIL) 流執行廣泛的分析，將其轉換為快速本機指令。運行庫根據需要使用實時 (JIT) 編譯器將 MSIL 指令轉換為本機代碼，每次轉換一個方法。例如，有一個類APP，其中包含了Main()方法和Add()方法：
{
?? public static int Main()
?? {
????? int ValueOne = 10;
????? int ValueTwo = 20;??????
????? Console.WriteLine("The Value is: {0}", Add(ValueOne, ValueTwo));
????? return 0;
?? }
?? public static int Add(int One, int Two)
?? {
????? return (One + Two);
?? }
}
通過運行庫，這段代碼被加載到內存中，并被轉化為MSIL：
.entrypoint
.maxstack? 3
.locals ([0] int32 ValueOne,
???????? [1] int32 ValueTwo,
???????? [2] int32 V_2,
???????? [3] int32 V_3)
IL_0000:? ldc.i4.s?? 10
IL_0002:? stloc.0
IL_0003:? ldc.i4.s?? 20
IL_0005:? stloc.1
IL_0006:? ldstr????? "The Value is: {0}"
IL_000b:? ldloc.0
IL_000c:? ldloc.1
IL_000d:? call int32 ConsoleApplication.MyApp::Add(int32,int32) /* 06000003 */
JIT 編譯器讀取整個方法的 MSIL，對其進行徹底地分析，然后為該方法生成有效的本機指令。在 IL_000d 遇到 Add 方法 (/* 06000003 */) 的元數據標記，運行庫使用該標記參考 MethodDef 表的第三行。
表4.2顯示了說明 Add 方法的元數據標記所引用的 MethodDef 表的一部分：
| 行 ? ? ?? | 相對虛擬地址 (RVA) ? ? ? | ImplFlags ? ? ? | Flags ? ? ? | Name ? ? ?（指向字符串堆） ? ? | Signature ? ? ?（指向 Blob 堆） ? ? |
表4.2 元數據標記
該表的每一列都包含有關代碼的重要信息。RVA 列允許運行庫計算定義該方法的 MSIL 的起始內存地址。ImplFlags 和 Flags 列包含說明該方法的位屏蔽（例如，該方法是公共的還是私有的）。Name 列對來自字符串堆的方法的名稱進行了索引。Signature 列對在 Blob 堆中的方法簽名的定義進行了索引。
通過利用元數據，我們就可以獲得類的相關信息。如上所述，在類APP的MethodDef表中，可以獲得類APP的三個方法，以及方法的Flags 和方法簽名。而在.Net中，則提供了反射技術，來支持這種對元數據信息的獲取。可以說，正是因為有了元數據，才使得AOP的攔截與織入功能的實現成為可 能。
4.2.2 Attribute
4.2.2.1 Attribute概述
通過對.Net元數據的分析，我們知道可以通過Attribute來擴展元數據。那么什么是Attribute？在MSDN中，Attribute 被定義為“是被指定給某一聲明的一則附加的聲明性信息”。 我們可以通過Attribute來定義設計層面的信息以及運行時（run-time）信息，也可以利用Attribute建立自描述（self- describing）組件。
Attribute可應用于任何目標元素，我們可以通過AttributeTargets枚舉指定其施加的目標，AttributeTargets枚舉在.Net中的定義如下：
C#語言: public enum AttributeTargets{
?? All=16383,
?? Assembly=1,
?? Module=2,
?? Class=4,
?? Struct=8,
?? Enum=16,
?? Constructor=32,
?? Method=64,
?? Property=128,
?? Field=256,
?? Event=512,
?? Interface=1024,
?? Parameter=2048,
?? Delegate=4096,
?? ReturnValue=8192
}
作為參數的AttributeTarges的值允許通過“或”操作來進行多個值的組合，如果你沒有指定參數，那么默認參數就是All 。
不管是.Net Framework提供的Attribute，還是用戶自定義Attribute，都是通過[]施加到目標元素上。雖然Attribute的用法與通常的 類型不一樣，但在.Net內部，Attribute本質上還是一個類。但是，Attribute類的實例化發生在編譯時，而非運行時，因而達到了擴展元數 據的目的。一個Attribute的多個實例可應用于同一個目標元素；并且Attribute可由從目標元素派生的元素繼承。
4.2.2.2自定義Attribute
.Net Framework支持用戶自定義Attribute。自定義Attribute的方法與定義類一樣，唯一不同之處是自定義的Attribute必須繼承 Attribute類。Attribute類包含用于訪問和測試自定義Attribute的簡便方法。其中，Attribute類的構造函數為 protected，只能被Attribute的派生類調用。Attribute類包含的方法主要為：
1．三個靜態方法
static Attribute GetCustomAttribute():這個方法有8種重載的版本，它被用來取出施加在類成員上指定類型的Attribute。
static Attribute[] GetCustomAttributes(): 這個方法有16種重載版本，用來取出施加在類成員上指定類型的Attribute數組。
static bool IsDefined()：有八種重載版本，看是否指定類型的定制attribute被施加到類的成員上面。
2．兩個實例方法
bool IsDefaultAttribute(): 如果Attribute的值是默認的值，那么返回true。
bool Match():表明這個Attribute實例是否等于一個指定的對象。
3．公共屬性
TypeId: 得到一個唯一的標識，這個標識被用來區分同一個Attribute的不同實例。
通過自定義Attribute，可使得用戶自定義的信息與Attribute施加的類本身相關聯。例如，給定一個自定義的 .NET 屬性，我們就可以輕松地將調用跟蹤Attribute與類的方法相關聯：
C#語言: public class Bar{
??? [CallTracingAttribute("In Bar ctor")]
??? public Bar() {}
??? [CallTracingAttribute("In Bar.Calculate method")]
??? public int Calculate(int x, int y){ return x + y; }
}
請注意，方括號中包含 CallTracingAttribute 和訪問方法時輸出的字符串。這是將自定義元數據與 Bar 的兩個方法相關聯的Attribute語法。該自定義的Attribute實現，如下所示：
C#語言:? using System;using System.Reflection;
[AttributeUsage( AttributeTargets.ClassMembers, AllowMultiple = false )]
public class CallTracingAttribute : Attribute
{???
??? private string m_TracingInfo;
??? public CallTracingAttribute(string info)
??? {
??????? m_TracingInfo = info;
??? }
??? public string TracingInfo
??? {
??????? get {return tracingInfo;}
??? }
}
通過自定義的CallTracingAttribute，將一段Tracing信息施加到類Bar的構造函數和方法Calculate上。我們可以利用反射技術與Attribute類提供的方法，來獲得Bar類的元數據中包含的Attribute信息，如：
C#語言: public class Test{
??? public static void Main(string[] args)
??? {
??????? System.Reflection.MemberInfo info = typeof(Bar);
??????? CallTracingAttribute attribute = (CallTracingAttribute) Attribute.GetCustomAttribute(info,typeof(CallTracingAttribute));
??????? if (attribute != null)
??????? {
???????????? Console.WriteLine(“Tracing Information:{0}”,attribute.TracingInfo);
??????? }
??? }
}
4.2.2.3上下文（Context）和Attribute
所謂上下文（Context），是指一個邏輯上的執行環境。每一個應用程序域都有一個或多個Context，.Net中的所有對象都會在相應的Context中創建和運行。如圖4.1所示，它顯示了一個安全地存在于Context的對象：
?
圖4.1 安全地存在于Context的對象
在圖4.1中，上下文（Context）提供了錯誤傳播、事務管理和同步功能，而對象的創建和運行就存在于該Context中。在.Net中，提供 了ContextBoundObject類，它代表的含義就是該對象應存在于指定的Context邊界中（Object that will be bound with a context）。凡是繼承了ContextBoundObject類的類類型，就自動具備了對象與Context之間的關系。事實上，如果一個類對象沒 有繼承自ContextBoundObject，則該對象默認會創建和運行在應用程序域的default context中，而繼承自ContextBoundObject的類對象，在其對象實例被激活時，CLR將自動創建一個單獨的Context供其生存。
如果需要判定ContextBoundObject類型對象所認定的Context，只需要為該類型對象施加ContextAttribute即 可。ContextAttribute類繼承了Attribute類，它是一個特殊的Attribute，通過它，可以獲得對象需要的合適的執行環境，即 Context（上下文）。同時，ContextAttribute還實現了IContextAttribute和IContextProperty接 口。
由于在施加Attribute時，只需要獲取ContextBoundObject類型的Context屬性，因此，我們也可以自定義 Attribute，只需要該自定義的Attribute實現IContextAttribute即可。IContextAttribute接口的定義如 下：
C#語言:? public interface IContextAttribute{
??? bool IsContextOK(Context ctx, IConstructionCallMessage ctorMsg);
??? void GetPropertiesForNewContext(IConstructionCallMessage ctorMsg);
}
每個context attribute在context的構造階段（通常是由ContextBoundObject對象構造動作引發的）會被首先問到 IsContextOK，就是說新創建的這個ContextBoundObjec（通過ctorMsg可以知道是哪個對象的哪個構造方法被用來構造 ContextBoundObjec對象的）能不能在給定的ctx中存在？這個目的主要是減少應用程序域中潛在的context的數量，如果某些 ContextBoundObjec類型可以共用一個有所需特性的執行環境的話，就可以不用再創建新的環境，而只要在已有的環境中構造并執行就好了。
如果ContextBoundObjec類型上設置的所有context attributes都認同給定的context（也即調用代碼所處的context）是正確地的（此時IsContextOK均返回true），那么新 的ContextBoundObjec就會被綁定到這個context上。否則，只有有一個attribute返回false，就會立即創建一個新的 context。然后，CLR會再一次詢問每一個context attribute新構造的context是否正確，由于Context已經被重新創建，通常此時返回的結果應為false。那么，Context構造程 序就會調用其GetPropertiesForNewContext()方法，context attribute可以用這個方法傳入的構造器方法調用信息（ctorMsg）中的context properties列表（ContextProperties）來為新建的context增加所需的context properties。
從AOP的角度來看，Context類似于前面分析的橫切關注點，那么利用我們自定義的Context Attribute，就可以獲得對象它所存在的上下文，從而建立業務對象與橫切關注點之間的關系。
4.2.3代理（Proxy）
在程序設計中使用代理（Proxy），最重要的目的是可以通過利用代理對象，實現代理所指向的真實對象的訪問。在GOF的《設計模式》中，將代理（Proxy）模式分為四種：
1、遠程代理（Remote Proxy）。它為一個位于不同的地址空間的對象提供一個局域代表對象。這個不同的地址空間可以是在本機器中，亦可是在另一臺機器中。
2、虛代理（Virtual Proxy）。它能夠根據需要創建一個資源消耗較大的對象，使得此對象只在需要時才會被真正創建。
3、保護代理（Protection Proxy）。它控制對原始對象的訪問，如果需要可以給不同的用戶提供不同級別的使用權限。
4、 智能引用代理（Smart Reference Proxy）。它取代了簡單的指針，在訪問一個對象時，提供一些額外的操作。例如，對指向實際對象的引用計數，這樣當該對象沒有引用時，可以自動釋放它。 當第一次引用一個持久對象時，智能引用可以將該對象裝入內存。在訪問一個實際對象前，檢查該對象是否被鎖定，以確保其他對象不能改變它。
在.Net Remoting中，采用了遠程代理（Remote Proxy）模式。采用代理技術，使得對象可以在兩個不同的應用程序域（甚至可以是兩臺不同的機器）之間傳遞。代理在.Net中被分為透明代理 （Transparent Proxy）和真實代理（Real Proxy）。Transparent Proxy的目標是在 CLR 中在 IL 層面最大程度扮演被代理的遠端對象，從類型轉換到類型獲取，從字段訪問到方法調用。對 CLR 的使用者來說，Transparent Proxy和被其代理的對象完全沒有任何區別，只有通過 RemotingServices.IsTransparentProxy 才能區分兩者的區別。Real Proxy則是提供給 CLR 使用者擴展代理機制的切入點，通過從Real Proxy繼承并實現 Invoke 方法，用戶自定義代理實現可以自由的處理已經被從棧調用轉換為消息調用的目標對象方法調用，如實現緩存、身份驗證、安全檢測、延遲加載等等。
如果我們希望自己定義的代理類能夠“模仿”真實對象的能力，首先就需要實現透明代理。然而，CLR中雖然提供了這樣一個透明代理類 （_TransparentProxy），我們卻不能讓自己的代理類從透明代理類派生，也不能通過自定義Attribute、實現標志性接口等方式將代理 類標識為透明代理，從而讓CLR能夠認識。要獲取透明代理，必須要提供一個真實代理。一個真實代理是一個從 System.Runtime.Remoting.Proxies.RealProxy派生而來的類。這個RealProxy類的首要功能就是幫我們在運 行期動態生成一個可以透明兼容于某一個指定類的透明代理類實例。從RealProxy的源代碼，可以看出透明代理和真實代理之間的關系：
C#語言:? namespace System.Runtime.Remoting.Proxies{
? abstract public class RealProxy
? {
??? protected RealProxy(Type classToProxy) : this(classToProxy, (IntPtr)0, null){}
??? protected RealProxy(Type classToProxy, IntPtr stub, Object stubData)
??? {
????? if(!classToProxy.IsMarshalByRef && !classToProxy.IsInterface)
??????? throw new ArgumentException(...);
????? if((IntPtr)0 == stub)
????? {
??????? stub = _defaultStub;
??????? stubData = _defaultStubData;
????? }
????? _tp = null;
????? if (stubData == null)
??????? throw new ArgumentNullException("stubdata");
????? _tp = RemotingServices.CreateTransparentProxy(this, classToProxy, stub, stubData);
??? }
??? public virtual Object GetTransparentProxy()
??? {
????? return _tp;
??? }
? }
}
很明顯，透明代理（Transparent Proxy）是在RealProxy類的構造函數中，調用RemotingServices.CreateTransparentProxy()方法動態 創建的。CreateTransparentProxy()方法將把被代理的類型強制轉換為統一的由 CLR 在運行時創建的 RuntimeType 類型，進而調用 Internal 方法完成TransparentProxy的創建。通過GetTransparentProxy()方法，就可以獲得創建的這個透明代理對象。因此，要定 義自己的真實代理對象，只需要繼承RealProxy類即可：
C#語言: using System.Runtime.Remoting.Proxies;public class MyRealProxy: RealProxy
{
? public MyRealProxy(Type classToProxy): base(classToProxy)
? {
?? // …
? }
}
透明代理和真實代理在上下文（Context）中，會起到一個偵聽器的作用。首先，透明代理將調用堆棧序列化為一個稱為消息（Message）的對 象，然后再將消息傳遞給真實代理。真實代理接收消息，并將其發送給第一個消息接收進行處理。第一個消息接收對消息進行預處理，將其繼續發送給位于客戶端和 對象之間的消息接收堆棧中的下一個消息接收，然后對消息進行后處理。下一個消息接收也如此照辦，以此類推，直到到達堆棧構建器接收，它將消息反序列化回調 用堆棧，調用對象，序列化出站參數和返回值，并返回到前面的消息接收。這個調用鏈如圖4.2所示。
?
圖4.2 代理（Proxy）偵聽消息的順序
由于透明代理完全等同于其代理的對象，因此，當我們偵聽到代理對象被調用的消息時，就可以截取該消息，并織入需要執行的方面邏輯，完成橫切關注邏輯與核心邏輯的動態代碼織入。
4.3 .Net平臺下AOP技術實現
4.3.1實現原理
根據對.Net中元數據（Metadata）、Attribute、上下 文（Context）、代理（Proxy）等技術要素的分析，要在.Net中實現AOP，首先需要獲得一個類對象的上下文（Context），則其前提就 是這個類必須從System.ContextBoundObject類派生。這個類對象就相當于AOP中的核心關注點，而類對象的上下文則屬于AOP的橫 切關注點。很顯然，只需要利用上下文，就可以方便的實現核心關注點和橫切關注點的分離。
正如圖4.1所示，對象是存在于上下文中的。利用自定義Attribute，可以建立對象與上下文之間的關聯。Attribute可以擴展對象的元 數據，從而標識出該對象屬于其中的一個或多個Aspect。一旦該對象實例被創建或調用時，就可以利用反射技術獲得該對象的自定義Attribute。為 使得對象的元數據與上下文關聯起來，就要求這個自定義的Attribute必須實現接口IContextAttribute。
獲得了對象的上下文之后，透明代理與真實代理就能夠對該對象的方法調用（包括構造函數）進行偵聽，并完成消息的傳遞。傳遞的消息可以被Aspect 截取，同時利用真實代理，也可以完成對業務對象的Decorate，將Aspect邏輯注入到業務對象中。由于在大型的企業系統設計中，橫切關注點會包括 事務管理、日志管理、權限控制等多方面，但由于方面（Aspect）在技術上的共同特性，我們可以利用.Net的相關技術實現方面（Aspect）的核心 類庫，所有的橫切關注點邏輯，都可以定義為派生這些類庫的類型，從而真正在.Net中實現AOP技術。
4.3.2 AOP公共類庫
4.3.2.1 AOP Attribute
如上所述，要實現AOP技術，首先需要自定義一個Attribute。該自定義Attribute必須實現IContextAttribute，因此其定義如下所示：
using System.Runtime.Remoting.Contexts;
using System.Runtime.Remoting.Activation;
[AttributeUsage(AttributeTargets.Class)]
public abstract class AOPAttribute:Attribute,IContextAttribute
{
??? private string m_AspectXml;
??? private const string CONFIGFILE = @"configuration\aspect.xml";
??? public AOPAttribute()???????????????????
??? {
??????? m_AspectXml = CONFIGFILE;
??? }??
??? public AOPAttribute(string aspectXml)
??? {
??????? this.m_AspectXml = aspectXml;
??? }?
??? protected abstract AOPProperty GetAOPProperty();
??? #region IContextAttribute Members
??? public sealed void GetPropertiesForNewContext(IConstructionCallMessage ctorMsg)
??? {
??????? AOPProperty property = GetAOPProperty();???
??????? property.AspectXml = m_AspectXml;????
??????? ctorMsg.ContextProperties.Add(property);
??? }
??? public bool IsContextOK(Context ctx, IConstructionCallMessage ctorMsg)
??? {
??????? return false;
??? }
}
類AOPAttribute除了繼承System.Attribute類之外，關鍵之處在于實現了接口IContextAttribute接口。接 口方法GetPropertiesForNewContext()其功能是向Context添加屬性（Property）集合，這個集合是 IConstructionCallMessage對象的ContextProperties屬性。而接口方法IsContextOK()，則用于判斷 Context中是否存在指定的屬性。這個方法會在Context的構造階段（通常是由被施加了AOPAttribute的業務對象在創建時引發的）被調 用，如果返回false，會創建一個新的Context。
GetAOPProperty()方法是一個受保護的抽象方法，繼承AOPAttribute的子類將重寫該方法，返回一個AOPProperty 對象。在這里，我們利用了Template Method模式，通過該方法創建符合條件的AOPProperty對象，并被GetPropertiesForNewContext()方法添加到屬性 集合中。
抽象類AOPAttribute是所有與方面有關的Attribute的公共基類。所有方面的相關Attribute均繼承自它，同時實現GetAOPProperty()方法，創建并返回與之對應的AOPProperty對象。
4.3.2.2 AOP Property
ContextProperties是一個特殊的集合對象，它存放的是對象被稱為Context Property，是一個實現了IContextProperty接口的對象，這個對象可以為相關的Context提供一些屬性。 IContextProperty接口的定義如下：
{
??? string Name { get; }
??? bool IsNewContextOK(Context newCtx);
??? void Freeze(Context newCtx);
}
IContextProperty接口的Name屬性，表示Context Property的名字，Name屬性值要求在整個Context中必須是唯一的。IsNewContextOK()方法用于確認Context是否存在 沖突的情況。而Freeze()方法則是通知Context Property，當新的Context構造完成時，則進入Freeze狀態（通常情況下，Freeze方法僅提供一個空的實現）。
由于IContextProperty接口僅僅是為Context提供一些基本信息，它并不能完成對方法調用消息的截取。根據對代理技術的分析，要 實現AOP，必須在方法調用截取消息傳遞，并形成一個消息鏈Message Sink。因此，如果需要向所在的Context的Transparent Proxy/Real Proxy中植入Message Sink，Context Property還需要提供Sink的功能。所幸的是，.Net已經提供了實現MessageSink功能的相關接口，這些接口的命名規則為 IContributeXXXSink，XXX代表了四種不同的 Sink：Envoy，ClientContext，ServerContext，Object。這四種接口有其相似之處，都只具有一個方法用于返回一個 IMessageSink對象。由于我們需要獲取的透明代理對象，是能夠穿越不同的應用程序域的。在一個應用程序域收到其他應用程序域的對象，則該對象 在.Net中被稱為Server Object，該對象所處的Context也被稱為Server Context。我們在.Net中實現AOP，其本質正是要獲得對象的Server Context，并截取該Context中的方法調用消息，因而Context Property對象應該實現IContributeServerContextSink接口。事實上，也只有 IContributeServerContextSink接口的GetServerContextSink()方法，才能攔截包括構造函數在內的所有方 法的調用。
因此，AOP Property最終的定義如下：
C#語言:? using System;using System.Runtime.Remoting.Activation;
using System.Runtime.Remoting.Contexts;
using System.Runtime.Remoting.Messaging;
public abstract class AOPProperty : IContextProperty, IContributeServerContextSink
{
??? private string m_AspectXml;
??? public AOPProperty()
??? {
??????? m_AspectXml = string.Empty;?????????
??? }
??? public string AspectXml
??? {
??????? set { m_AspectXml = value; }
??? }
??? protected abstract IMessageSink CreateAspect(IMessageSink nextSink);
??? protected virtual string GetName()
??? {
??????? return "AOP";
??? }
??? protected virtual void FreezeImpl(Context newContext)
??? {
??????? return;
??? }
??? protected virtual bool CheckNewContext(Context newCtx)
??? {
??????? return true;
??? }
??? #region IContextProperty Members
??? public void Freeze(Context newContext)
??? {
??????? FreezeImpl(newContext);
??? }
??? public bool IsNewContextOK(Context newCtx)
??? {
??????? return CheckNewContext(newCtx);
??? }
??? public string Name
??? {
??????? get { return GetName(); }
??? }
??? #endregion
??? #region IContributeServerContextSink Members
??? public IMessageSink GetServerContextSink(IMessageSink nextSink)
??? {
??????? Aspect aspect = (Aspect)CreateAspect(nextSink);??????????
??????? aspect.ReadAspect(m_AspectXml,Name);??????????
??????? return (IMessageSink)aspect;
??? }
??? #endregion
}
在抽象類AOPProperty中，同樣利用了Template Method模式，將接口IContextProperty的方法的實現利用受保護的虛方法延遲到繼承AOPProperty的子類中。同時，對于接口 IContributeServerContextSink方法GetServerContextSink()，則創建并返回了一個Aspect類型的對 象，Aspect類型實現了IMessageSink接口，它即為AOP中的方面，是所有方面（Aspect）的公共基類。
AOPProperty類作為抽象類，是所有與上下文有關的Property的公共基類。作為Context Property應與Aspect相對應，且具體的AOPProperty類對象應在AOPAttribute的子類中創建并獲得。
4.3.2.3 Aspect與PointCut
Aspect類是AOP的核心，它的本質是一個Message Sink，代理正是通過它進行消息的傳遞，并截獲方法間傳遞的消息。Aspect類實現了IMessageSink接口，其定義如下：
{
??? IMessage SyncProcessMessage(IMessage msg);
??? IMessageCtrl AsyncProcessMessage(IMessage msg, IMessageSink replySink);
??? IMessageSink NextSink { get; }???
}
IMessageSink接口利用NextSink將多個Message Sink連接起來，以形成一個消息接收器鏈；而SyncProcessMessage()和AsyncProcessMessage()方法則分別用于同步和異步操作，它們在消息傳遞的時候被調用。
注意方法SyncProcessMessage()中的參數，是一個IMessage接口類型的對象。在.Net 中，IMethodCallMessage和IMethodReturnMessage接口均繼承自IMessage接口，前者是調用方法的消息，而后者 則是方法被調用后的返回消息。利用這兩個接口對象，就可以獲得一個對象方法的切入點。因此，一個最簡單的Aspect實現應該如下：
C#語言: public abstract class Aspect : IMessageSink{????
??? private IMessageSink m_NextSink;
??? public AOPSink(IMessageSink nextSink)
??? {
??????? m_NextSink = nextSink;???????
??? }
??? public IMessageSink NextSink
??? {
??????? get { return m_NextSink; }
??? }
??? public IMessage SyncProcessMessage(IMessage msg)
??? {
??????? IMethodCallMessage call = msg as IMethodCallMessage;
??????? if (call == null)
??????? {
???????????? return null;
??????? }
??????? IMessage retMsg = null;
??????? BeforeProcess();
??????? retMsg = m_NextSink.SyncProcessMessage(msg);
??????? AfterProcess();
??????? return retMsg;
??? }
??? public IMessageCtrl AsyncProcessMessage(IMessage msg, IMessageSink replySink)
??? {
???????? return null;
??? }
??? private void BeforeProcess()
??? {
???????? //方法調用前的實現邏輯；
??? }
??? private void AfterProcess()
??? {
???????? //方法調用后的實現邏輯；
??? }
}
注意在方法SyncProcessMessage()中，IMessageSink對象m_NextSink通過Aspect構造函數賦值為業務對 象的透明代理，在調用m_NextSink的SyncProcessMessage()方法時，此時調用的是與該透明代理對應的真實代理。如果在消息接收 鏈中還存在代理，在方法調用將會沿著消息鏈不斷的向后執行。而對于一個業務對象而言，此時的IMessage即為該對象中被調用的方 法，SyncProcessMessage(msg)就相當于執行了該方法。而在m_NextSink.SyncProcessMessage(msg) 方法前后執行BeforeProcess()和AfterProcess()，就完成了對方法的截取，并將自己的Aspect邏輯織入到業務對象的方法調用中，從而實現了AOP。
然而對于AOP技術的實際應用而言，并非業務對象的所有方法都需要被截取進而進行方面的織入。也即是說，切入點（PointCut）必須實現可被用 戶定義。而所謂切入點，實際上是業務對象方法與Advice之間的映射關系。在.Net中，我們可以通過集合對象來管理這個映射關系。由于Advice包 括Before Advice和After Advice，因此，在Aspect類中應該定義兩個集合對象：
C#語言:? private SortedList m_BeforeAdvices;private SortedList m_AfterAdvices;
在添加PointCut時，是將方法名和具體的Advice對象建立映射，根據SortedList集合的特性，我們將方法名作為SortedList的Key，而Advice則作為SortedList的Value：
C#語言:? protected virtual void AddBeforeAdvice(string methodName, IBeforeAdvice before){
??? lock (this.m_BeforeAdvices)
??? {
??????? if (!m_BeforeAdvices.Contains(methodName))
??????? {
??????????? m_BeforeAdvices.Add(methodName, before);
??????? }
??? }
}
protected virtual void AddAfterAdvice(string methodName, IAfterAdvice after)
{
??? lock (this.m_AfterAdvices)
??? {
??????? if (!m_AfterAdvices.Contains(methodName))
??????? {
??????????? m_AfterAdvices.Add(methodName, after);
??????? }
??? }
}
在向SortedList添加PointCut時，需要先判斷集合中是否已經存在該PointCut。同時考慮到可能存在并發處理的情況，在添加PointCut時，利用lock對該操作進行了加鎖，避免并發處理時可能會出現的錯誤。
建立了方法名和Advice的映射關系，在執行SyncProcessMessage()方法，就可以根據IMessage的值，獲得業務對象被調用方法的相關屬性，然后根據方法名，找到其對應的Advice，從而執行相關的Advice代碼：
C#語言:? public IMessage SyncProcessMessage(IMessage msg){??????????
????? IMethodCallMessage call = msg as IMethodCallMessage;
????? string methodName = call.MethodName.ToUpper();
????? IBeforeAdvice before = FindBeforeAdvice(methodName);
????? if (before != null)
????? {
?????????? before.BeforeAdvice(call);
????? }??????????
????? IMessage retMsg = m_NextSink.SyncProcessMessage(msg);
????? IMethodReturnMessage reply = retMsg as IMethodReturnMessage;
????? IAfterAdvice after = FindAfterAdvice(methodName);
????? if (after != null)
????? {
??????????? after.AfterAdvice(reply);
????? }
????? return retMsg;
}
其中FindBeforeAdvice()和FindAfterAdvice()方法完成key和value的查找工作，分別的定義如下：
C#語言:? public IBeforeAdvice FindBeforeAdvice(string methodName){
??? IBeforeAdvice before;
??? lock (this.m_BeforeAdvices)
??? {
??????? before = (IBeforeAdvice)m_BeforeAdvices[methodName];
??? }
??? return before;
}
public IAfterAdvice FindAfterAdvice(string methodName)
{
??? IAfterAdvice after;
??? lock (this.m_AfterAdvices)
??? {
??????? after = (IAfterAdvice)m_AfterAdvices[methodName];
??? }
??? return after;
}
在找到對應的Advice對象后，就可以調用Advice對象的相關方法，完成方面邏輯代碼的織入。
那么，PointCut是在什么時候添加的呢？我們可以在AOP的配置文件（Aspect.xml）中配置PointCut，然后在Aspect類 中，通過ReadAspect()方法，讀入配置文件，獲取PointCut以及Aspect需要的信息，包括方法名和Advice對象（通過反射動態創 建），在執行AddBeforeAdvice()和AddAfterAdvice()方法將PointCut添加到各自的集合對象中：
C#語言:? public void ReadAspect(string aspectXml,string aspectName){
??? IBeforeAdvice before = (IBeforeAdvice)Configuration.GetAdvice(aspectXml,aspectName,Advice.Before);
??? string[] methodNames = Configuration.GetNames(aspectXml,aspectName,Advice.Before);
??? foreach (string name in methodNames)
??? {
???????? AddBeforeAdvice(name,before);
??? }
??? IAfterAdvice after = (IAfterAdvice)Configuration.GetAdvice(aspectXml,aspectName,Advice.After);
??? string[] methodNames = Configuration.GetNames(aspectXml,aspectName,Advice.After);
??? foreach (string name in methodNames)
??? {
???????? AddAfterAdvice(name,after);
??? }??
}
一個Aspect的配置文件示例如下：
XML語言:? <aop>??? <aspect value ="LogAOP">
??????? <advice type="before" assembly="AOP.Advice" class="AOP.Advice.LogAdvice">
???? <pointcut>ADD</pointcut>
???? <pointcut>SUBSTRACT</pointcut>
</advice>
<advice type="after" assembly="AOP.Advice" class="AOP.Advice.LogAdvice">
???? <pointcut>ADD</pointcut>
???? <pointcut>SUBSTRACT</pointcut>
</advice>
??? </aspect>
</aop>
配置文件中，元素Advice的assembly屬性和class屬性值，是利用反射創建Advice對象所需要的信息。另外，Aspect的名字 應與方面的Property名保持一致，因為ReadAspect()方法是通過AOPProperty名字來定位配置文件的Aspect。
4.3.2.4 Advice
在Aspect類中，已經使用了Advice對象。根據類別不同，這些Advice對象分別實現IBeforeAdvice接口和IAfterAdvice接口：
using System.Runtime.Remoting.Messaging;
public interface IBeforeAdvice
{
??? void BeforeAdvice(IMethodCallMessage callMsg);
}
public interface IAfterAdvice
{
??? void AfterAdvice(IMethodReturnMessage returnMsg);
}
接口方法應該實現具體的方面邏輯，同時可以通過IMethodCallMessage對象獲得業務對象的調用方法信息，通過IMethodReturnMessage對象獲得方法的返回信息。
4.4 .Net平臺AOP技術應用案例
在4.3.2節，我們已基本實現了AOP的公共類庫，這其中包括 AOPAttribute，AOPProperty，Aspect，IBeforeAdvice，IAfterAdvice。根據這些公共基類或接口，我 們就可以定義具體的方面，分別繼承或實現這些類與接口。為了展示AOP在.Net中的應用，在本節，我將以一個簡單的實例來說明。
假定我們要設計一個計算器，它能提供加法和減法功能。我們希望，在計算過程中，能夠通過日志記錄整個計算過程及其結果，同時需要監測其運算性能。該 例中，核心業務是加法和減法，而公共的業務則是日志與監測功能。根據前面對AOP的分析，這兩個功能作為橫切關注點，將是整個系統需要剝離出來的“方面 ”。
4.4.1日志方面
???? 作為日志方面，其功能就是要截取業務對象方法的調用，并獲取之間傳遞的消息內容。從上節的分析我們知道，方法間的消息可以從 IMethodCallMessage和IMethodReturnMessage接口對象獲得。因此，實現日志方面，最重要的是實現Aspect類中的 SyncProcessMessage()方法。此外，也應定義與之對應的Attribute和Property，以及實現日志邏輯的Advice。
4.4.1.1日志Attribute（LogAOPAttribute）
LogAOPAttribute類繼承AOPAttribute，由于AOPAttribute類主要是創建并獲得對應的AOPProperty，因此，其子類也僅需要重寫父類的受保護抽象方法GetAOPProperty()即可：
public class LogAOPAttribute:AOPAttribute
{
?????? public LogAOPAttribute():base()
?????? {}
?????? public LogAOPAttribute(string aspectXml):base(aspectXml)
?????? {}
?????? protected override AOPProperty GetAOPProperty()
?????? {
????????????? return new LogAOPProperty();
?????? }??
}
通過對GetAOPProperty()方法的重寫，創建并獲得了與LogAOPAttribute類相對應的LogAOPProperty，此時 在LogAOPAttribute所施加的業務對象的上下文中，所存在的AOP Property就應該是具體的LogAOPProperty對象。
4.4.1.2日志Property（LogAOPProperty）
由于Context Property的名字在上下文中必須是唯一的，因此每個方面的Property的名字也必須是唯一的。因此在繼承AOPProperty的子類 LogAOPProperty中，必須重寫父類的虛方法GetName()，同時在LogAOPProperty中，還應該創建與之對應的Aspect， 也即是Message Sink，而這個工作是由抽象方法CreateAspect()來完成的。因此，LogAOPProperty類的定義如下：
{
?????? protected override IMessageSink CreateAspect(IMessageSink nextSink)
?????? {
????????????? return new LogAspect(nextSink);
?????? }
?????? protected override string GetName()
?????? {
????????????? return "LogAOP";
?????? }
}
為避免Property的名字出現重復，約定成俗以方面的Attribute名為Property的名字，以本例而言，其Property名為LogAOP。
4.4.1.3日志Aspect（LogAspect）
LogAspect完成的功能主要是將Advice與業務對象的方法建立映射，并將 其添加到Advice集合中。由于我們在AOP實現中，利用了xml配置文件來配置PointCut，因此對于所有Aspect而言，這些操作都是相同 的，只要定義了正確的配置文件，將其讀入即可。對于Aspect的SyncProcessMessage()，由于攔截和織入的方法是一樣的，不同的只是 Advice的邏輯而已，因此在所有Aspect的公共基類中已經提供了默認的實現：
{
?????? public LogAspect(IMessageSink nextSink):base(nextSink)
?????? {}??????????
}
然后定義正確的配置文件：
XML語言: <aspect value ="LogAOP">??? <advice type="before" assembly=" AOP.Advice" class="AOP.Advice.LogAdvice">
??????? <pointcut>ADD</pointcut>
<pointcut>SUBSTRACT</pointcut>
??? </advice>
??? <advice type="after" assembly=" AOP.Advice" class="AOP.Advice.LogAdvice">
<pointcut>ADD</pointcut>
<pointcut>SUBSTRACT</pointcut>
??? </advice>
</aspect>
LogAdvice所屬的程序集文件為AOP.Advice.dll，完整的類名為AOP.Advice.LogAdvice。
4.4.1.4日志Advice（LogAdvice）
由于日志方面需要記錄方法調用前后的相關數據，因此LogAdvice應同時實現IBeforeAdvice和IAfterAdvice接口：
{
??? #region IBeforeAdvice Members
??? public void BeforeAdvice(IMethodCallMessage callMsg)
??? {
??????? if (callMsg == null)
??????? {
??????????? return;
??????? }
??????? Console.WriteLine("{0}({1},{2})", callMsg.MethodName, callMsg.GetArg(0), callMsg.GetArg(1));
??? }
??? #endregion
??? #region IAfterAdvice Members
??? public void AfterAdvice(IMethodReturnMessage returnMsg)
??? {
??????? if (returnMsg == null)
??????? {
??????????? return;
??????? }
??????? Console.WriteLine("Result is {0}", returnMsg.ReturnValue);
??? }
??? #endregion
}
在BeforeAdvice()方法中，消息類型為IMethodCallMessage，通過這個接口對象，可以獲取方法名和方法調用的參數值。 與之相反，AfterAdvice()方法中的消息類型為IMethodReturnMessage，Advice所要獲得的數據為方法的返回值 ReturnValue。
4.4.2性能監測方面
性能監測方面與日志方面的實現大致相同，為簡便起見，我要實現的性能監測僅僅是記錄方法調用前和調用后的時間。
4.4.2.1性能監測Attribute（MonitorAOPAttribute）
與日志Attribute相同，MonitorAOPAttribute僅僅需要創建并返回對應的MonitorAOPProperty對象：
public class MonitorAOPAttribute:AOPAttribute
{
?????? public MonitorAOPAttribute():base()
?????? {}
?????? public MonitorAOPAttribute(string aspectXml):base(aspectXml)
?????? {}
?????? protected override AOPProperty GetAOPProperty()
?????? {
????????????? return new MonitorAOPProperty();
?????? }
}
4.4.2.2性能監測Property（MonitorAOPProperty）
MonitorAOPProperty的屬性名將定義為MonitorAOP，使其與日志方面的屬性區別。除定義性能監測方面的屬性名外，還需要重寫CreateAspect()方法，創建并返回對應的方面對象MonitorAspect：
{
?????? protected override IMessageSink CreateAspect(IMessageSink nextSink)
?????? {
????????????? return new MonitorAspect(nextSink);
?????? }
?????? protected override string GetName()
?????? {
????????????? return "MonitorAOP";
?????? }
}
4.4.2.3性能監測Aspect（MonitorAspect）
MonitorAspect類的實現同樣簡單：
{
???????? public MonitorAspect(IMessageSink nextSink):base(nextSink)
???????? {}
}
而其配置文件的定義則如下所示：
XML語言:? <aspect value ="MonitorAOP">??? <advice type="before" assembly=" AOP.Advice" class="AOP.Advice.MonitorAdvice">
??????? <pointcut>ADD</pointcut>
<pointcut>SUBSTRACT</pointcut>
??? </advice>
??? <advice type="after" assembly=" AOP.Advice" class="AOP.Advice.MonitorAdvice">
<pointcut>ADD</pointcut>
<pointcut>SUBSTRACT</pointcut>
??? </advice>
</aspect>
MonitorAdvice所屬的程序集文件為AOP.Advice.dll，完整的類名為AOP.Advice.MonitorAdvice。
4.4.2.4性能監測Advice（MonitorAdvice）
由于性能監測方面需要記錄方法調用前后的具體時間，因此MonitorAdvice應同時實現IBeforeAdvice和IAfterAdvice接口：
{
??? #region IBeforeAdvice Members
??? public void BeforeAdvice(IMethodCallMessage callMsg)
??? {
??????? if (callMsg == null)
??????? {
??????????? return;
??????? }
??????? Console.WriteLine("Before {0} at {1}", callMsg.MethodName, DateTime.Now);
??? }
??? #endregion
??? #region IAfterAdvice Members
??? public void AfterAdvice(IMethodReturnMessage returnMsg)
??? {
??????? if (returnMsg == null)
??????? {
??????????? return;
??????? }
??????? Console.WriteLine("After {0} at {1}", returnMsg.MethodName, DateTime.Now);
??? }
??? #endregion
}
MonitorAdvice只需要記錄方法調用前后的時間，因此只需要分別在BeforeAdvice()和AfterAdvice()方法中，記錄當前的時間即可。
4.4.3業務對象與應用程序
4.4.3.1業務對象（Calculator）
通過AOP技術，我們已經將核心關注點和橫切關注點完全分離，我們在定義業務對象時，并不需要關注包括日志、性能監測等方面，這也是AOP技術的優勢。當然，由于要利用.Net中的Attribute及代理技術，對于施加了方面的業務對象而言，仍然需要一些小小的限制。
首先，我們應該將定義好的方面Aspect施加給業務對象。其次，由于代理技術要獲取業務對象的上下文（Context），該上下文必須是指定的， 而非默認的上下文。上下文的獲得，是在業務對象創建和調用的時候，如果要獲取指定的上下文，在.Net中，要求業務對象必須繼承 ContextBoundObject類。因此，最后業務對象Calculator類的定義如下所示：
C#語言: [MonitorAOP][LogAOP]
public class Calculator : ContextBoundObject
{
?????? public int Add(int x,int y)
?????? {
????????????? return x + y;
?????? }
?????? public int Substract(int x,int y)
?????? {
????????????? return x - y;
?????? }
}
[MonitorAOP]和[LogAOP]正是之前定義的方面Attribute，此外Calculator類繼承了 ContextBoundObject。除此之外，Calculator類的定義與普通的對象定義無異。然而，正是利用AOP技術，就可以攔截 Calculator類的Add()和Substract()方法，對其進行日志記錄和性能監測。而實現日志記錄和性能監測的邏輯代碼，則完全與 Calculator類的Add()和Substract()方法分開，實現了兩者之間依賴的解除，有利于模塊的重用和擴展。
4.4.3.2應用程序（Program）
我們可以實現簡單的應用程序，來看看業務對象Calculator施加了日志方面和性能檢測方面的效果：
{?????????
?????? [STAThread]
?????? static void Main(string[] args)
?????? {
????????????? Calculator cal = new Calculator();
????????????? cal.Add(3,5);
????????????? cal.Substract(3,5);
????????????? Console.ReadLine();
?????? }
}
程序創建了一個Calculator對象，同時調用了Add()和Substract()方法。由于Calculator對象被施加了日志方面和性能檢測方面，因此運行結果會將方法調用的詳細信息和調用前后的運行當前時間打印出來，如圖4.3所示：
?
圖4.3 施加了方面的業務對象調用結果
如果要改變記錄日志和性能監測結果的方式，例如將其寫到文件中，則只需要改變
總結
以上是生活随笔為你收集整理的AOP技术研究 再续的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： android 调用java接口_and
- 下一篇： phoenix的元数据一般存在哪里_Ph