深圳嘉华_架构师进阶之路_15AOP概述

一、引言

AOP(Aspect-Oriented Programming,面向方面编程),它利用一种称为“横切”的技术,剖解开封装的对象内部,并将那些影响了多个类的公共行为封装到一个可重用模块,并将其名为“Aspect”,即方面。所谓“方面”,简单地说,就是将那些与业务无关,却为业务模块所共同调用的逻辑或责任封装起来,便于减少系统的重复代码,降低模块间的耦合度,并有利于未来的可操作性和可维护性。AOP代表的是一个横向的关系,如果说“对象”是一个空心的圆柱体,其中封装的是对象的属性和行为;那么面向方面编程的方法,就仿佛一把利刃,将这些空心圆柱体剖开,以获得其内部的消息。而剖开的切面,也就是所谓的“方面”了。然后它又以巧夺天功的妙手将这些剖开的切面复原,不留痕迹。

1、AOP的技术

实现AOP的技术,主要分为两大类:一是采用动态代理技术,利用截取消息的方式,对该消息进行装饰,以取代原有对象行为的执行;二是采用静态织入的方式,引入特定的语法创建“方面”,从而使得编译器可以在编译期间织入有关“方面”的代码。然而殊途同归,实现AOP的技术特性却是相同的,分别为:

1、join point(连接点):是程序执行中的一个精确执行点,例如类中的一个方法。它是一个抽象的概念,在实现AOP时,并不需要去定义一个join point。
2、point cut(切入点):本质上是一个捕获连接点的结构。在AOP中,可以定义一个point cut,来捕获相关方法的调用。
3、advice(通知):是point cut的执行代码,是执行“方面”的具体逻辑。
4、aspect(方面):point cut和advice结合起来就是aspect,它类似于OOP中定义的一个类,但它代表的更多是对象间横向的关系。
5、introduce(引入):为对象引入附加的方法或属性,从而达到修改对象结构的目的。有的AOP工具又将其称为mixin。

上述的技术特性组成了基本的AOP技术,大多数AOP工具均实现了这些技术。它们也可以是研究AOP技术的基本术语。

1.1、横切技术

“横切”是AOP的专有名词。它是一种蕴含强大力量的相对简单的设计和编程技术,尤其是用于建立松散耦合的、可扩展的企业系统时。横切技术可以使得AOP在一个给定的编程模型中穿越既定的职责部分(比如日志记录和性能优化)的操作。

如果不使用横切技术,软件开发是怎样的情形呢?在传统的程序中,由于横切行为的实现是分散的,开发人员很难对这些行为进行逻辑上的实现或更改。例如,用于日志记录的代码和主要用于其它职责的代码缠绕在一起。根据所解决的问题的复杂程度和作用域的不同,所引起的混乱可大可小。更改一个应用程序的日志记录策略可能涉及数百次编辑——即使可行,这也是个令人头疼的任务。

在AOP中,我们将这些具有公共逻辑的,与其他模块的核心逻辑纠缠在一起的行为称为“横切关注点(Crosscutting Concern)”,因为它跨越了给定编程模型中的典型职责界限。

1.1.1、横切关注点

一个关注点(concern)就是一个特定的目的,一块我们感兴趣的区域,一段我们需要的逻辑行为。从技术的角度来说,一个典型的软件系统包含一些核心的关注点和系统级的关注点。举个例子来说,一个信用卡处理系统的核心关注点是借贷/存入处理,而系统级的关注点则是日志、事务完整性、授权、安全及性能问题等,许多关注点——即横切关注点(crosscutting concerns)——会在多个模块中出现。如果使用现有的编程方法,横切关注点会横越多个模块,结果是使系统难以设计、理解、实现和演进。AOP能够比上述方法更好地分离系统关注点,从而提供模块化的横切关注点。

例如一个复杂的系统,它由许多关注点组合实现,如业务逻辑、性能,数据存储、日志和调度信息、授权、安全、线程、错误检查等,还有开发过程中的关注点,如易懂、易维护、易追查、易扩展等,图2.1演示了由不同模块实现的一批关注点组成一个系统。
在这里插入图片描述
通过对系统需求和实现的识别,我们可以将模块中的这些关注点分为:核心关注点和横切关注点。对于核心关注点而言,通常来说,实现这些关注点的模块是相互独立的,他们分别完成了系统需要的商业逻辑,这些逻辑与具体的业务需求有关。而对于日志、安全、持久化等关注点而言,他们却是商业逻辑模块所共同需要的,这些逻辑分布于核心关注点的各处。在AOP中,诸如这些模块,都称为横切关注点。应用AOP的横切技术,关键就是要实现对关注点的识别。

如果将整个模块比喻为一个圆柱体,那么关注点识别过程可以用三棱镜法则来形容,穿越三棱镜的光束(指需求),照射到圆柱体各处,获得不同颜色的光束,最后识别出不同的关注点。如图2.2所示:
在这里插入图片描述
上图识别出来的关注点中,Business Logic属于核心关注点,它会调用到Security,Logging,Persistence等横切关注点。

public class BusinessLogic
{
    public void SomeOperation()
    {
       //验证安全性;Securtity关注点;
       //执行前记录日志;Logging关注点;
       DoSomething();
       //保存逻辑运算后的数据;Persistence关注点;
       //执行结束记录日志;Logging关注点;
    }
}

AOP的目的,就是要将诸如Logging之类的横切关注点从BusinessLogic类中分离出来。利用AOP技术,可以对相关的横切关注点封装,形成单独的“aspect”。这就保证了横切关注点的复用。由于BusinessLogic类中不再包含横切关注点的逻辑代码,为达到调用横切关注点的目的,可以利用横切技术,截取BusinessLogic类中相关方法的消息,例如SomeOperation()方法,然后将这些“aspect”织入到该方法中。例如图2.3:
在这里插入图片描述
通过利用AOP技术,改变了整个系统的设计方式。在分析系统需求之初,利用AOP的思想,分离出核心关注点和横切关注点。在实现了诸如日志、事务管理、权限控制等横切关注点的通用逻辑后,开发人员就可以专注于核心关注点,将精力投入到解决企业的商业逻辑上来。同时,这些封装好了的横切关注点提供的功能,可以最大限度地复用于商业逻辑的各个部分,既不需要开发人员作特殊的编码,也不会因为修改横切关注点的功能而影响具体的业务功能。

为了建立松散耦合的、可扩展的企业系统,AOP应用到的横切技术,通常分为两种类型:动态横切和静态横切。

1.1.2、 动态横切

动态横切是通过切入点和连接点在一个方面中创建行为的过程,连接点可以在执行时横向地应用于现有对象。动态横切通常用于帮助向对象层次中的各种方法添加日志记录或身份认证。在很多应用场景中,动态横切技术基本上代表了AOP。

动态横切技术的核心主要包括join point(连接点),point cut(切入点),advice(通知)和aspect(方面)。在前面,我已经概要地介绍了这些术语分别代表的含义。接下来,我将以一个具体的实例来进一步阐述它们在AOP动态横切中实现的意义。

考虑一个电子商务系统,需要对订单进行添加、删除等管理操作。毫无疑问,在实际的应用场景中,这些行为应与权限管理结合,只有获得授权的用户方能够实施这些行为。采用传统的设计方法,其伪代码如下:

public class OrderManager
{
    private ArrayList m_Orders;
    public OrderManager()
    {
       m_Orders = new ArrayList();
    }
    public void AddOrder(Order order)
    {
        if (permissions.Verify(Permission.ADMIN))
        {
            m_Orders.Add(order);
        }
    }

    public void RemoveOrder(Order order)
    {
        if (permissions.Verify(Permission.ADMIN))
        {
            m_Orders.Remove(order);
        }
    }
}

同样的,在该电子商务系统中,还需要对商品进行管理,它采用了同样的授权机制:

public class ProductManager
{
    private ArrayList m_Products;
    public ProductManager()
    {
        m_Products = new ArrayList();
    }
    public void AddProduct(Product product)
    {
        if (permissions.Verify(Permission.ADMIN))
        {
             m_Products.Add(product);
        }
    }
    public void RemoveProduct(Product product)
    {
        if (permissions.Verify(Permission.ADMIN))
        {
             m_Products.Remove(product);
        }
    }
}

如此以来,在整个电子商务系统中,核心业务包括订单管理和商品管理,它们都需要相同的权限管理,如图2.4所示:
在这里插入图片描述
毫无疑问,利用AOP技术,我们可以分离出系统的核心关注点和横切关注点,从横向的角度,截取业务管理行为的内部消息,以达到织入权限管理逻辑的目的。当执行AddOrder()等方法时,系统将验证用户的权限,调用横切关注点逻辑,因此该方法即为AOP的join point。对于电子商务系统而言,每个需要权限验证的方法都是一个单独的join point。由于权限验证将在每个方法执行前执行,所以对于这一系列join point,只需要定义一个point cut。当系统执行到join point处时,将根据定义去查找对应的point cut,然后执行这个横切关注点需要实现的逻辑,即advice。而point cut和advice,就组合成了一个权限管理aspect。
在这里插入图片描述
由于aspect是一个封装的对象,我们可以定义这样一个aspect:

private static aspect AuthorizationAspect{……}

然后在这个aspect中定义point cut,在point cut中,定义了需要截取上下文消息的方法,例如:

private pointcut authorizationExecution():
execution(public void OrderManager.AddOrder(Order)) ||
execution(public void OrderManager.DeleteOrder(Order)) ||
execution(public void ProductManager.AddProduct(Product)) ||
execution(public void ProductManager.DeleteProduct(Product));

由于权限验证是在订单管理方法执行之前完成,因此在before advice中,定义权限检查:

before(): authorizationExecution()
{
    if !(permissions.Verify(Permission.ADMIN))
    {
        throw new UnauthorizedException();
    }
}

通过定义了这样一个完整的aspect,当系统调用OrderManager或ProductManager的相关方法时,就触发了point cut,然后调用相应的advice逻辑。如此以来,OrderManager和ProductManager模块就与权限管理模块完全解除了依赖关系,同时也消除了传统设计中不可避免的权限判断的重复代码。这对于建立一个松散耦合、可扩展的系统软件是非常有利的。

1.1.3、 静态横切

静态横切和动态横切的区别在于它不修改一个给定对象的执行行为。相反,它允许通过引入附加的方法字段和属性来修改对象的结构。此外,静态横切可以把扩展和实现附加到对象的基本结构中。在AOP实现中,通常将静态横切称为introduce或者mixin。

静态横切在AOP技术中,受到的关注相对较少。事实上,这一技术蕴含的潜力是巨大的。使用静态横切,架构师和设计者能用一种真正面向对象的方法有效地建立复杂系统的模型。静态横切允许您不用创建很深的层次结构,以一种本质上更优雅、更逼真于现实结构的方式,插入跨越整个系统的公共行为。尤其是当开发应用系统时,如果需要在不修改原有代码的前提下,引入第三方产品和API库,则静态横切技术将发挥巨大的作用。

举例来说,当前已经实现了一个邮件收发系统,其中类Mail完成了收发邮件的功能。但在产品交付后,发现该系统存在缺陷,在收发邮件时,未曾实现邮件地址的验证功能。现在,第三方产品已经提供了验证功能的接口IValidatable:

public interface IValidatable
{
    bool ValidateAddress();
}

我们可以利用设计模式中的Adapter模式,来完成对第三方产品API的调用。我们可以定义一个新的类MailAdapter,该类实现了IValidatable接口,同时继承了Mail类:

public class MailAdapter:Mail,IValidatable
{
     public bool ValidateAddress()
     {
         if(this.getToAddress() != null)
         {
             return true;
         }
         else
         {
             return false;
         }
     }
}

通过引入MailAdapter类,原来Mail对象完成的操作,将全部被MailAdapter对象取代。然而,此种实现方式虽然能解决引入新接口的问题,但类似下面的代码,却是无法编译通过的:

Mail mail = new Mail();
IValidatable validate = ((IValidatable)mail).ValidateAddress();

必须将第一行代码作如下修改:
Mail mail = new MailAdapter();

利用AOP的静态横切技术,可以将IValidatable接口织入到原有的Mail类中,这是一种非常形象的introduce功能,其实现仍然是在aspect中完成:

mport com.acme.validate.Validatable;

public aspect MailValidateAspect
{
    declare parents: Mail implements IValidatable;

    public boolean Mail.validateAddress()
    {
         if(this.getToAddress() != null)
         {
              return true;
         }
         else
         {
              return false;
         }
    }
}

静态横切的方法,并没有引入类似MailAdapter的新类,而是通过定义的MailValidateAspect方面,利用横切技术为Mail类introduce了新的方法ValidateAddress(),从而实现了Mail的扩展。因此如下的代码完全可行。
Mail mail = new Mail();
IValidatable validate = ((IValidatable)mail).ValidateAddress();

2、 AOP技术的优势

设计软件系统时应用AOP技术,其优势在于:

(一)在定义应用程序对某种服务(例如日志)的所有需求的时候。通过识别关注点,使得该服务能够被更好的定义,更好的被编写代码,并获得更多的功能。这种方式还能够处理在代码涉及到多个功能的时候所出现的问题,例如改变某一个功能可能会影响到其它的功能,在AOP中把这样的麻烦称之为“纠结(tangling)”。

(二)利用AOP技术对离散的方面进行的分析将有助于为开发团队指定一位精于该项工作的专家。负责这项工作的最佳人选将可以有效利用自己的相关技能和经验。

(三)持久性。标准的面向对象的项目开发中,不同的开发人员通常会为某项服务编写相同的代码,例如日志记录。随后他们会在自己的实施中分别对日志进行处理以满足不同单个对象的需求。而通过创建一段单独的代码片段,AOP提供了解决这一问题的持久简单的方案,这一方案强调了未来功能的重用性和易维护性:不需要在整个应用程序中一遍遍重新编写日志代码,AOP使得仅仅编写日志方面(logging aspect)成为可能,并且可以在这之上为整个应用程序提供新的功能。

总而言之,AOP技术的优势使得需要编写的代码量大大缩减,节省了时间,控制了开发成本。同时也使得开发人员可以集中关注于系统的核心商业逻辑。此外,它更利于创建松散耦合、可复用与可扩展的大型软件系统。

3、.Net平台下实现AOP的技术基础

如前所述,在.Net平台下实现AOP,采用的方式主要是静态织入和动态织入的方式。在本文中,我将充分利用.Net的技术特性,包括元数据、Attribute、.Net Remoting的代理技术,将其综合运用,最终以动态织入的方式实现AOP公共类库。本节将介绍实现AOP所必需的.Net知识。

3.1、元数据(metadata)

元数据是一种二进制信息,用以对存储在公共语言运行库(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 文件发出用户自己的自定义元数据。

3.1.1、元数据的结构

在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部分的内容

PE部分
PE部分的内容
表4.1 PE文件中的元数据

3.1.2、元数据在运行时的作用

由于在MSIL指令中包含了元数据标记,因此,当公共语言运行库(CLR)将代码加载到内存时,将向元数据咨询该代码模块中包含的信息。运行库对Microsoft 中间语言 (MSIL) 流执行广泛的分析,将其转换为快速本机指令。运行库根据需要使用实时 (JIT) 编译器将 MSIL 指令转换为本机代码,每次转换一个方法。例如,有一个类APP,其中包含了Main()方法和Add()方法:

using System; 

public class App
{
   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 表的第三行。

通过利用元数据,我们就可以获得类的相关信息。如上所述,在类APP的MethodDef表中,可以获得类APP的三个方法,以及方法的Flags和方法签名。而在.Net中,则提供了反射技术,来支持这种对元数据信息的获取。可以说,正是因为有了元数据,才使得AOP的拦截与织入功能的实现成为可能。

3.2、 Attribute

3.2.1、Attribute概述

通过对.Net元数据的分析,我们知道可以通过Attribute来扩展元数据。那么什么是Attribute?在MSDN中,Attribute被定义为“是被指定给某一声明的一则附加的声明性信息”。 我们可以通过Attribute来定义设计层面的信息以及运行时(run-time)信息,也可以利用Attribute建立自描述(self-describing)组件。

Attribute可应用于任何目标元素,我们可以通过AttributeTargets枚举指定其施加的目标,AttributeTargets枚举在.Net中的定义如下:

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可由从目标元素派生的元素继承。

3.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与类的方法相关联:

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实现,如下所示:

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信息,如:

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);
        }
    }
}

3.2.3、上下文(Context)和Attribute

所谓上下文(Context),是指一个逻辑上的执行环境。每一个应用程序域都有一个或多个Context,.Net中的所有对象都会在相应的Context中创建和运行。如图4.1所示,它显示了一个安全地存在于Context的对象:

上下文(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接口的定义如下:
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,就可以获得对象它所存在的上下文,从而建立业务对象与横切关注点之间的关系。

3.2.4、代理(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的源代码,可以看出透明代理和真实代理之间的关系:

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类即可:

using System.Runtime.Remoting.Proxies;

public class MyRealProxy: RealProxy
{
  public MyRealProxy(Type classToProxy): base(classToProxy)
  {}
}

根据对.Net中元数据(Metadata)、Attribute、上下文(Context)、代理(Proxy)等技术要素的分析,要在.Net中实现AOP,首先需要获得一个类对象的上下文(Context),则其前提就是这个类必须从System.ContextBoundObject类派生。这个类对象就相当于AOP中的核心关注点,而类对象的上下文则属于AOP的横切关注点。很显然,只需要利用上下文,就可以方便的实现核心关注点和横切关注点的分离。

对象是存在于上下文中的。利用自定义Attribute,可以建立对象与上下文之间的关联。Attribute可以扩展对象的元数据,从而标识出该对象属于其中的一个或多个Aspect。一旦该对象实例被创建或调用时,就可以利用反射技术获得该对象的自定义Attribute。为使得对象的元数据与上下文关联起来,就要求这个自定义的Attribute必须实现接口IContextAttribute。

获得了对象的上下文之后,透明代理与真实代理就能够对该对象的方法调用(包括构造函数)进行侦听,并完成消息的传递。传递的消息可以被Aspect截取,同时利用真实代理,也可以完成对业务对象的Decorate,将Aspect逻辑注入到业务对象中。由于在大型的企业系统设计中,横切关注点会包括事务管理、日志管理、权限控制等多方面,但由于方面(Aspect)在技术上的共同特性,我们可以利用.Net的相关技术实现方面(Aspect)的核心类库,所有的横切关注点逻辑,都可以定义为派生这些类库的类型,从而真正在.Net中实现AOP技术。

3.3、AOP公共类库

3.3.1、AOP Attribute

如上所述,要实现AOP技术,首先需要自定义一个Attribute。该自定义Attribute必须实现

IContextAttribute,因此其定义如下所示:
using System;
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对象。

3.3.2、AOP Property

ContextProperties是一个特殊的集合对象,它存放的是对象被称为Context Property,是一个实现了IContextProperty接口的对象,这个对象可以为相关的Context提供一些属性。IContextProperty接口的定义如下:

public interface 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最终的定义如下:

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的子类中创建并获得。

3.3.3、Aspect与PointCut

Aspect类是AOP的核心,它的本质是一个Message Sink,代理正是通过它进行消息的传递,并截获方法间传递的消息。Aspect类实现了IMessageSink接口,其定义如下:

public interface 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实现应该如下:

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类中应该定义两个集合对象:

private SortedList m_BeforeAdvices;
private SortedList m_AfterAdvices;

在添加PointCut时,是将方法名和具体的Advice对象建立映射,根据SortedList集合的特性,我们将方法名作为SortedList的Key,而Advice则作为SortedList的Value:

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代码:

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的查找工作,分别的定义如下:
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添加到各自的集合对象中:

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的配置文件示例如下:

<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。

3.3.4、Advice

在Aspect类中,已经使用了Advice对象。根据类别不同,这些Advice对象分别实现IBeforeAdvice接口和IAfterAdvice接口:

using System;
using System.Runtime.Remoting.Messaging;
public interface IBeforeAdvice
{
    void BeforeAdvice(IMethodCallMessage callMsg);
}
public interface IAfterAdvice
{
    void AfterAdvice(IMethodReturnMessage returnMsg);
}

接口方法应该实现具体的方面逻辑,同时可以通过IMethodCallMessage对象获得业务对象的调用方法信息,通过IMethodReturnMessage对象获得方法的返回信息。

4、.Net平台AOP技术应用案例

前面我们已基本实现了AOP的公共类库,这其中包括AOPAttribute,AOPProperty,Aspect,IBeforeAdvice,IAfterAdvice。根据这些公共基类或接口,我们就可以定义具体的方面,分别继承或实现这些类与接口。为了展示AOP在.Net中的应用,在本节,我将以一个简单的实例来说明。

假定我们要设计一个计算器,它能提供加法和减法功能。我们希望,在计算过程中,能够通过日志记录整个计算过程及其结果,同时需要监测其运算性能。该例中,核心业务是加法和减法,而公共的业务则是日志与监测功能。根据前面对AOP的分析,这两个功能作为横切关注点,将是整个系统需要剥离出来的“方面”。

4.1、日志方面

 作为日志方面,其功能就是要截取业务对象方法的调用,并获取之间传递的消息内容。从上节的分析我们知道,方法间的消息可以从IMethodCallMessage和IMethodReturnMessage接口对象获得。因此,实现日志方面,最重要的是实现Aspect类中的SyncProcessMessage()方法。此外,也应定义与之对应的Attribute和Property,以及实现日志逻辑的Advice。

4.1.1、日志Attribute(LogAOPAttribute)

LogAOPAttribute类继承AOPAttribute,由于AOPAttribute类主要是创建并获得对应的AOPProperty,因此,其子类也仅需要重写父类的受保护抽象方法GetAOPProperty()即可:

[AttributeUsage(AttributeTargets.Class)]
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.1.2、日志Property(LogAOPProperty)

由于Context Property的名字在上下文中必须是唯一的,因此每个方面的Property的名字也必须是唯一的。因此在继承AOPProperty的子类LogAOPProperty中,必须重写父类的虚方法GetName(),同时在LogAOPProperty中,还应该创建与之对应的Aspect,也即是Message Sink,而这个工作是由抽象方法CreateAspect()来完成的。因此,LogAOPProperty类的定义如下:

public class LogAOPProperty:AOPProperty
{
       protected override IMessageSink CreateAspect(IMessageSink nextSink)
       {
              return new LogAspect(nextSink);
       }
       protected override string GetName()
       {
              return "LogAOP";
       }
}

为避免Property的名字出现重复,约定成俗以方面的Attribute名为Property的名字,以本例而言,其Property名为LogAOP。

4.1.3、日志Aspect(LogAspect)

LogAspect完成的功能主要是将Advice与业务对象的方法建立映射,并将其添加到Advice集合中。由于我们在AOP实现中,利用了xml配置文件来配置PointCut,因此对于所有Aspect而言,这些操作都是相同的,只要定义了正确的配置文件,将其读入即可。对于Aspect的SyncProcessMessage(),由于拦截和织入的方法是一样的,不同的只是Advice的逻辑而已,因此在所有Aspect的公共基类中已经提供了默认的实现:

public class LogAspect:Aspect
{
       public LogAspect(IMessageSink nextSink):base(nextSink)
       {}           
}

然后定义正确的配置文件:

<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.1.4、日志Advice(LogAdvice)

由于日志方面需要记录方法调用前后的相关数据,因此LogAdvice应同时实现IBeforeAdvice和IAfterAdvice接口:

 public class LogAdvice:IAfterAdvice,IBeforeAdvice
{
    #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.2、性能监测方面

性能监测方面与日志方面的实现大致相同,为简便起见,我要实现的性能监测仅仅是记录方法调用前和调用后的时间。

4.2.1、性能监测Attribute(MonitorAOPAttribute)

与日志Attribute相同,MonitorAOPAttribute仅仅需要创建并返回对应的MonitorAOPProperty对象:

[AttributeUsage(AttributeTargets.Class)]
public class MonitorAOPAttribute:AOPAttribute
 {
        public MonitorAOPAttribute():base()
        {}
        public MonitorAOPAttribute(string aspectXml):base(aspectXml)
        {}
        protected override AOPProperty GetAOPProperty()
        {
               return new MonitorAOPProperty();
        } 
 }

4.2.2、性能监测Property(MonitorAOPProperty)

MonitorAOPProperty的属性名将定义为MonitorAOP,使其与日志方面的属性区别。除定义性能监测方面的属性名外,还需要重写CreateAspect()方法,创建并返回对应的方面对象MonitorAspect:

public class MonitorAOPProperty:AOPProperty
{
       protected override IMessageSink CreateAspect(IMessageSink nextSink)
       {
              return new MonitorAspect(nextSink);
       }
       protected override string GetName()
       {
              return "MonitorAOP";
       }
}

4.2.3、性能监测Aspect(MonitorAspect)

MonitorAspect类的实现同样简单:

public class MonitorAspect:Aspect
{
	public MonitorAspect(IMessageSink nextSink):base(nextSink)
	{}
}

而其配置文件的定义则如下所示:

<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.2.4、性能监测Advice(MonitorAdvice)

由于性能监测方面需要记录方法调用前后的具体时间,因此MonitorAdvice应同时实现IBeforeAdvice和IAfterAdvice接口:

public class 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()方法中,记录当前的时间即可。

5、业务对象与应用程序

5.1、业务对象(Calculator)

通过AOP技术,我们已经将核心关注点和横切关注点完全分离,我们在定义业务对象时,并不需要关注包括日志、性能监测等方面,这也是AOP技术的优势。当然,由于要利用.Net中的Attribute及代理技术,对于施加了方面的业务对象而言,仍然需要一些小小的限制。

首先,我们应该将定义好的方面Aspect施加给业务对象。其次,由于代理技术要获取业务对象的上下文(Context),该上下文必须是指定的,而非默认的上下文。上下文的获得,是在业务对象创建和调用的时候,如果要获取指定的上下文,在.Net中,要求业务对象必须继承ContextBoundObject类。因此,最后业务对象Calculator类的定义如下所示:

[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()方法分开,实现了两者之间依赖的解除,有利于模块的重用和扩展。

5.2、应用程序(Program)

我们可以实现简单的应用程序,来看看业务对象Calculator施加了日志方面和性能检测方面的效果:

class Program
{          
       [STAThread]
       static void Main(string[] args)
       {
              Calculator cal = new Calculator();
              cal.Add(3,5);
              cal.Substract(3,5);
              Console.ReadLine();
       }
}
发布了37 篇原创文章 · 获赞 3 · 访问量 6305

猜你喜欢

转载自blog.csdn.net/huan13479195089/article/details/105131301
今日推荐