在.Net中关于AOP的实现
 

2010-04-21 作者:conan 来源:conan的blog

 

一、AOP实现初步

AOP将软件系统分为两个部分:核心关注点和横切关注点。核心关注点更多的是Domain Logic,关注的是系统核心的业务;而横切关注点虽与核心的业务实现无关,但它却是一种更Common的业务,各个关注点离散地分布于核心业务的多处。这意味着,如果不应用AOP,那么这些横切关注点所代表的业务代码,就会分散在系统各处,导致系统中的每个模块都与这些业务具有很强的依赖性。在这里,所谓横切关注点所代表的业务,即为“方面(Aspect)”,常见的包括权限控制、日志管理、事务处理等等。

 

以权限控制为例,假设一个电子商务系统,需要对订单管理用户进行权限判定,只有系统用户才能添加、修改和删除订单,那么传统的设计方法是:

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

    }

}

}

这样的设计其缺陷是将订单管理业务与权限管理完全结合在一起,耦合度高。而在一个系统中,类似的权限控制会很多,这些代码就好像一颗颗毒瘤一般蔓延于系统中的各处,一旦需要扩展,则给程序员们带来的困难是不可估量的。

 

让我们来观察一下订单管理业务中的权限管理。不管是添加订单,还是删除订单,有关权限管理的内容是完全相同的。那么,为什么我们不能将这些相同的业务,抽象为一个对象,并将其从订单管理业务中完全剥离出来呢?在传统的OO设计思想,这种设想是不能实现的。因为订单管理业务作为一个类对象,它封装了诸如添加、删除订单等行为。这种封装性,就决定了我们不可能切入到对象内部,通过获取方法消息的形式,对对象行为进行监控与操作。

 

AOP的思想解决了这个问题,之所以称为“方面(Aspect)”,就是把这些对象剖开,仅获取其内部相一致的逻辑,并剥离出来,以“方面”的形式存在。要让这些方面能够对核心业务进行控制,就需要有一套获取方法消息的机制。在.Net中,其中一种技术称为动态代理。

 

.Net中,要实现动态代理,需要用到.Net Remoting中的消息机制,以及.Net Framework内部提供的ContextAttribute类来自定义自己的Attribute。另外,.Net还要求调用“Aspect”的核心业务类,必须继承ContextBoundObject类。只有这样,我们才能截取其内部传递的方法消息。以下,是相关接口和类的说明。

ContextAttribute

该类继承了Attribute类,它是一个特殊的Attribute,通过它,可以获得对象需要的合适的执行环境,即Context(上下文)。它还实现了IContextAttributeIContextProperty接口。我们自定义的Attribute将从ContextAttribute类派生。

构造函数:

ContextAttribute类的构造函数带有一个参数,用来设置ContextAttribute的名称。

公共属性:

Name只读属性。返回ContextAttribute的名称

公共方法:

GetPropertiesForNewContext:虚拟方法。向新的Context添加属性集合。

IsContextOK虚拟方法。查询客户Context中是否存在指定的属性。

IsNewContextOK虚拟方法。默认返回true。一个对象可能存在多个Context,使用这个方法来检查新的Context中属性是否存在冲突。

Freeze:虚拟方法。该方法用来定位被创建的Context的最后位置。

 

ContextBoundObject

这个类的对象通过Attribute来指定它所在的Context凡是进入该Context的调用都可以被拦截。该类从MarshalByRefObject派生。

 

IMessage:定义了被传送的消息的实现。一个消息必须实现这个接口。

 

IMessageSink:定义了消息接收器的接口,一个消息接收器必须实现这个接口。

该接口主要提供了两个方法,分别进行同步和异步操作:

SyncProcessMessage(IMessage msg):接口方法,当消息传递的时候,该方法被调用;

AsyncProcessMessage(IMessage msg, IMessageSink replySink):该方法用于异步处理;

 

下面是实现权限控制AOP的简单实现,首先我们自定义一个Attribute,它继承了ContextAttribute

[AttributeUsage(AttributeTargets.Class)]

    public class AOPAttribute:ContextAttribute

    {

        public AOPAttribute()

            : base("AOP")

        {

        }

 

        public override void GetPropertiesForNewContext(IConstructionCallMessage ctorMsg)

        {

            ctorMsg.ContextProperties.Add(new AOPProperty());

        }

    }

GetPropertiesForNewContext()方法中,添加了AOPProperty对象,它是一个上下文环境属性:

    public class AOPProperty : IContextProperty, IContributeObjectSink

    {

        public AOPProperty()

        {

        }

 

        #region IContributeObjectSink Members

 

        public IMessageSink GetObjectSink(MarshalByRefObject obj, IMessageSink nextSink)

        {

            return new AOPSink(nextSink);

        }

 

        #endregion

 

        #region IContextProperty Members

 

        public void Freeze(Context newContext)

        {           

        }

 

        public bool IsNewContextOK(Context newCtx)

        {

            return true;

        }

 

        public string Name

        {

            get { return "AOP"; }

        }

 

        #endregion

AOPProperty属性实现了接口IContextPropertyIContributeObjectSinkGetObjectSink()方法为IContributeObjectSink接口的方法,在其实现中,创建了一个IMessageSink对象AOPSink,该对象实现了IMessageSink接口:

    public class AOPSink : 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;

if (call.MethodName == "AddOrder" || call.MethodName == "DeleteOrder")

{

    if (permissions.Verify(Permission.ADMIN))

    {

          retMsg = m_NextSink.SyncProcessMessage(msg);

    }

}           

            return retMsg;

        }

 

        public IMessageCtrl AsyncProcessMessage(IMessage msg, IMessageSink replySink)

        {

            return null;

        }

    }

AOPSink中,最重要的是SyncProcessMessage()方法,在这个方法中,实现了权限控制,并通过IMessage,截取了需要权限控制的方法。在检验了权限之后,然后再执行OrderManagerAddOrderDeleteOrder方法。

 

通过AOP的实现,原来的OrderManager,就可以修改为:

[AOP]

public class OrderManager: ContextBoundObject

{

private ArrayList m_Orders;

public OrderManager()

{

       m_Orders = new ArrayList();

}

public void AddOrder(Order order)

{

    m_Orders.Add(order);

}

public void RemoveOrder(Order order)

{

    m_Orders.Remove(order);

}

}

在上述的OderManager类中,完全消除了permissions.Verify()等有关权限的代码,解除了订单管理与权限管理之间的耦合。

 

二、与AspectJ比较

上述的方案虽然解除了订单管理与权限管理的耦合,但从SyncProcessMessage()方法可以看出,它的实现具有很大的局限性。试想一下这样的应用场景,在订单管理系统中,用户要求对修改订单的方法增加权限验证,同时要求在验证权限时,允许业务经理(Permission.Manager)也具备管理订单的权限,应该怎样做?仔细思考,我们会发觉以上的实现未免太过死板了。

 

让我们来参考一下AspectJjava中的实现。AspectJ提供了自己的一套语法,其中包括aspectpointcutbeforeafter等。我们可以通过aspect定义一个“方面”,如上的权限管理:

private static aspect AuthorizationAspect{……}

 

pointcut为切入点,在其中定义了需要截取上下文消息的方法,例如:

private pointcut authorizationExecution():

execution(public void OrderManager.AddOrder(Order)) ||

execution(public void OrderManager.DeleteOrder(Order)) ||

execution(public void OrderManager.UpdateOrder(Order));

 

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

before(): authorizationExecution()

{

if !(permissions.Verify(Permission.ADMIN))

{

    throw new UnauthorizedException();

}

}

从上述AspectJ的实现中,我们可以看到,要定义自己的aspect是非常容易的,而通过pointcut的方式,可以将需要截取消息的方法,集中在一起。beforeafter则是具体的方面执行的逻辑,它们就好像Decorator模式那样,对原有方法进行了一层装饰,从而达到将aspect代码植入的目的。

 

另外,AspectJ还提供了更简单的语法,可以简化前面pointcut中一系列方法的列举:

private pointcut authorizationExecution():

execution (public * OrderManager.*(.))

 

AspectJ在应用AOP领域,已经非常成熟。它提供了自成一体的特有AspectJ语法,并需要专门的java编译器,使用起来较为复杂。那么,在.Net下,可否实现类似AspectJ的功能呢?我想,由于.Netjava在很多技术的相似性,它们彼此之间在很多领域是相通的,因此要达到这一目标应该是可行的。事实上,开源项目中的Aspect#,就与AspectJ相似。

 

事实上,如果我们利用前面描述的动态代理机制,辅以设计模式的OO设计方法,直接在代码中也可以实现AspectJ中的部分AOP特性。

 

三、.NetAOP的深入实现

我们先分析AspectJ中的pointcut.Net中的SyncProcessMessage()方法。Pointcut可以添加一系列需要截取上下文的方法,那么在.Net中,我们也可以利用集合,动态地添加方法,并创建这些方法与“方面”的映射。同样的,AspectJ中的beforeafter,是“方面”的核心实现,那么在.Net中,我们也可以利用委托,使其对应相关的方法,来实现其核心逻辑。

 

结合动态代理的知识,我们先定义两个委托,分别代表beforeafter操作:

public delegate void BeforeAOPHandle(IMethodCallMessage callMsg);

public delegate void AfterAOPHandle(IMethodReturnMessage replyMsg);

 

BeforeAOPHandle中的参数callMsg,其值为要截取上下文的方法的消息;AfterAOPHandle中的参数replyMsg,则是该方法执行后返回的消息。

 

接下来,定义一个抽象基类AOPSink,它实现了IMessageSink接口:

public abstract class AOPSink : IMessageSink

    {

        private SortedList m_BeforeHandles;

        private SortedList m_AfterHandles;

        private IMessageSink m_NextSink;

}

在类AOPSink中,定义了两个SortedList类型的字段:m_BeforeHandlesm_AfterHandles。它们负责存放方法名与BeforeAOPHandleAfterAOPHandle对象之间的映射。添加这些映射的职责由如下两个方法完成:

protected virtual void AddBeforeAOPHandle(string methodName, BeforeAOPHandle beforeHandle)

{

     lock (this.m_BeforeHandles)

     {

         if (!m_BeforeHandles.Contains(methodName))

         {

             m_BeforeHandles.Add(methodName, beforeHandle);

         }

     }

}

protected virtual void AddAfterAOPHandle(string methodName, AfterAOPHandle afterHandle)

{

      lock (this.m_AfterHandles)

      {

          if (!m_AfterHandles.Contains(methodName))

          {

              m_AfterHandles.Add(methodName, afterHandle);

          }

      }

}

考虑到我们要截取的方法可能会有多个,因此在类AOPSink中,又定义了两个抽象方法,负责添加所有的映射关系:

protected abstract void AddAllBeforeAOPHandles();

protected abstract void AddAllAfterAOPHandles();

 

然后在构造函数中,我们初始化两个SortedList对象,并调用上述的两个抽象方法:

        public AOPSink(IMessageSink nextSink)

        {

            m_NextSink = nextSink;

            m_BeforeHandles = new SortedList();

            m_AfterHandles = new SortedList();

            AddAllBeforeAOPHandles();

            AddAllAfterAOPHandles();

        }

 

为了能够根据方法名获得相对应的委托对象,我们又定义了两个Find方法。考虑到可能会有多个用户同时调用,在这两个方法中,我利用lock避免了对象的争用:

        protected BeforeAOPHandle FindBeforeAOPHandle(string methodName)

        {

            BeforeAOPHandle beforeHandle;

            lock (this.m_BeforeHandles)

            {

                beforeHandle = (BeforeAOPHandle)m_BeforeHandles[methodName];

            }

            return beforeHandle;

        }

        protected AfterAOPHandle FindAfterAOPHandle(string methodName)

        {

            AfterAOPHandle afterHandle;

            lock (this.m_AfterHandles)

            {

                afterHandle = (AfterAOPHandle)m_AfterHandles[methodName];

            }

            return afterHandle;

        }

接下来是IMessageSink接口要求实现的方法和属性:

        public IMessageSink NextSink

        {

            get { return m_NextSink; }

        }

 

        public IMessage SyncProcessMessage(IMessage msg)

        {

            IMethodCallMessage call = msg as IMethodCallMessage;

            string methodName = call.MethodName.ToUpper();

            BeforeAOPHandle beforeHandle = FindBeforeAOPHandle(methodName);

            if (beforeHandle != null)

            {

                beforeHandle(call);

            }

            IMessage retMsg = m_NextSink.SyncProcessMessage(msg);

            IMethodReturnMessage replyMsg = retMsg as IMethodReturnMessage;

            AfterAOPHandle afterHandle = FindAfterAOPHandle(methodName);

            if (afterHandle != null)

            {

                afterHandle(replyMsg);

            }

            return retMsg;

        }

 

        public IMessageCtrl AsyncProcessMessage(IMessage msg, IMessageSink replySink)

        {

            return null;

        }

需要注意的是SyncProcessMessage()方法。在该方法中,通过FindBeforeAOPHandle()FindAfterAOPHandle()方法,找到BeforeAOPHandleAfterAOPHandle委托对象,并执行它们。即执行这两个委托对象具体指向的方法,类似与AspectJ中的beforeafterexecution

 

现在,我们就可以象AspectJ那样定义自己的aspect了。如权限管理一例,我们定义一个类AuthorizationAOPSink,它继承了AOPSink

public class AuthorizationAOPSink : AOPSink

{

    public AuthorizationAOPSink(IMessageSink nextSink)

            : base(nextSink)

   {

   }

}

然后在这个方法中,实现beforeafter的逻辑。注意beforeafter方法应与之前定义的委托BeforeAOPHandleAfterAOPHandle一致。不过,以本例而言,并不需要实现after逻辑:

private void Before_Authorization(IMethodCallMessage callMsg)

{      

        if (callMsg == null)

        {

              return;

        }

        if (!permissions.Verify(Permission.ADMIN))

        {

                 throw UnauthorizedException();

         }

}

然后我们override基类中的抽象方法AddAllBeforeAOPHandles()AddAllAfterAOPHandles()

protected override void AddAllBeforeAOPHandles()

        {

            AddBeforeAOPHandle("ADDORDER", new BeforeAOPHandle(Before_Authorization));

            AddBeforeAOPHandle("DELETEORDER", new BeforeAOPHandle(Before_Authorization));

        }

 

        protected override void AddAllAfterAOPHandles()

        {           

        }

因为after逻辑不需要实现,因此重写AddAllAfterAOPHandles()时,使其为空就可以了(必须重写,因为该方法为抽象方法)。在AOPProperty类中,需要返回IMessageSink对象,所以还应修改原来的AOPProperty类中的GetObjectSink方法:

public IMessageSink GetObjectSink(MarshalByRefObject obj, IMessageSink nextSink)

        {

            return new AOPSink(nextSink);

return new AuthorizationAOPSink(nextSink);       

        }

 

比较一下上述的实现方案,自定义的继承AOPSink类的AuthorizationAOPSink就相当于AspectJ中的aspect。而与BeforeAOPHandleAfterAOPHandle委托对应的方法,则相当于AspectJbeforeafter语法。AddAllBeforeAOPHandles()AddAllAfterAOPHandle()则相当于AspectJpointcut。通过引入委托的方法,使得我们的AOP实现,具有了AspectJ的一些特性,而这些实现是不需要专门的编译器的。

 

很明显,如果我们要求OrderManager类中新增的UpdateOrder方法,也要加入权限控制,那么我们可以在AddAllBeforeAOPHandles()方法中,增加UpdaeOrder方法与before逻辑的映射:

AddBeforeAOPHandle("UPDATEORDER", Before_Authorization);

同样的,如果要对权限控制进行修改,开发业务经理对订单管理的权限,那么也只需要修改Before_Authorization()方法:

private void Before_Authorization(IMessage callMsg)

{

       IMethodCallMessage call = callMsg as IMethodCallMessage;

        if (call == null)

        {

              return;

        }

        if (!(permissions.Verify(Permission.ADMIN)|| permissions.Verify(Permission.MANAGER)))

        {

                 throw UnauthorizedException();

         }

}

 

四、进一步完善

由于我们的委托列表m_BeforeHandlesm_AfterHandlesSortedList类型,因此作为keymethodName必须是唯一的。如果系统要求添加其他权限控制的逻辑,例如增加认证功能,就不能再在AuthorizationAOPSink类的AddAllBeforeAOPHandles()方法中增加方法名与认证功能的before逻辑之间的映射了。

private void Before_Authentication(IMessage callMsg){……}

protected override void AddAllBeforeAOPHandles()

{

       ……

       AddBeforeAOPHandle("ADDORDER", new BeforeAOPHandle(Before_ Authentication));

       AddBeforeAOPHandle("DELETEORDER", new BeforeAOPHandle(Before_ Authentication));

}

如果在AuthorizationAOPSink类中添加上面的代码,由于新增的“ADDORDERkey与前面重复,故执行程序时,是找不到相应的委托Before_Authentication的。

 

解决的办法就是为认证功能新定义一个aspect。由于在本方案中,实现AOP功能的不仅仅是实现了IMessageSink接口的AOPSink类,同时该类还与PropertyAttribute有关。也就是说,如果我们新定义一个AuthenticationAOPSink,那么还要定义与之对应的AuthenticationAOPProperty类。为便于扩展,我采用了Template Method模式,为所有的property定义了抽象类AOPProperty,其中的抽象方法或虚方法,则留待其子类来实现。

    public abstract class AOPProperty : IContextProperty, IContributeObjectSink

    {

        protected abstract IMessageSink CreateSink(IMessageSink nextSink);

        protected virtual string GetName()

        {

            return "AOP";

        }

 

        protected virtual void FreezeImpl(Context newContext)

        {

            return;

        }

        protected virtual bool CheckNewContext(Context newCtx)

        {

            return true;

        }

 

        #region IContributeObjectSink Members

        public IMessageSink GetObjectSink(MarshalByRefObject obj, IMessageSink nextSink)

        {

            return CreateSink(nextSink);

        }

        #endregion

 

        #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

}

与原来的AOPProperty类相比,IContextPropertyIContributeObjectSink接口的方法与属性,都没有直接实现,而是在其内部调用了相关的抽象方法和虚方法。包括:抽象方法CreateSink(),虚方法FreezeImpl()CheckNewContext()以及GetName()。对于其子类而言,需要override的,主要是抽象方法CreateSink()GetName()(因为PropertyName必须是唯一的),至于其他虚方法,可以根据需要选择是否override。例如,自定义权限控制的属性类AuthorizationAOPProperty

    public class AuthorizationAOPProperty :AOPProperty

    {   

        protected override IMessageSink CreateSink(IMessageSink nextSink)

        {

            return new AuthorizationAOPSink(nextSink);

        }

 

        protected override string GetName()

        {

            return "AuthorizationAOP";

        }

    }

在该类中,我们overrideCreateSink()方法,创建了一个AuthorizationAOPSink对象。同时override了虚方法GetName,返回了自己的一个名字“AuthorizationAOP”。

 

关于Attribute类,观察其方法GetPropertiesForNewContext(),其实现是在IConstructionCallMessage消息的上下文property中添加自定义property。这些property组成了一个链,它是可以静态添加的。鉴于此,我们可以采取两种策略:

1、 所有的aspect都使用同一个Attribute。其实现如下:

    [AttributeUsage(AttributeTargets.Class)]

    public class AOPAttribute:ContextAttribute

    {

        public AOPAttribute()

            : base("AOP")

        {

        }

 

        public override void GetPropertiesForNewContext(IConstructionCallMessage ctorMsg)

        {

            ctorMsg.ContextProperties.Add(new AuthorizationAOPProperty());

            ctorMsg.ContextProperties.Add(new AuthenticationAOPProperty());

        }

}

在方法GetPropertiesForNewContext()中,添加多个自定义Property。在添加Property时,需要注意添加Property的顺序。

2、 不同的aspect使用不同的Attribute。此时可以为这些Attribute定义一个共同的抽象基类AOPAttribute

[AttributeUsage(AttributeTargets.Class)]

    public abstract class AOPAttribute:ContextAttribute

    {

         public AOPAttribute()

             : base("AOP")

         {

         }

 

         public sealed override void GetPropertiesForNewContext(IConstructionCallMessage ctorMsg)

         {

             ctorMsg.ContextProperties.Add(GetAOPProperty());

         }

 

         protected abstract AOPProperty GetAOPProperty();        

    }

注:我将GetPropertiesForNewContext()方法sealed,目的是不需要其子类在重写该方法。

 

继承AOPAttribute类的子类只需要重写GetAOPProperty()方法即可。但在为OrderManager类定义Attribute的时候,需注意其顺序。如以下的顺序:

[AuthorizationAOP]

[AuthenticationAOP]

public class OrderManager{}

此时,AuthorizationAOPAttribute在前,AuthenticationAOPAttribute在后。如果以Decorator的角度来看,对被装饰的方法,AuthorizationAOPAttribute在内,AuthenticationAOPAttribute在外。

考虑到aspect的应用,有的方法需要多个aspect,有的则只需要单个aspect,所以,第二个方案更佳。

 

五、AOP实例

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

 

我们已经拥有了一个AOP实现机制,以及核心的类库,包括AOPSinkAOPPropertyAOPAttribute三个抽象基类。现在,我们分别为日志aspect和监测aspect,定义相应的SinkPropertyAttribute

 

首先是日志aspect

LogAOPSink.cs:

using System;

using System.Runtime.Remoting.Messaging;

using Wayfarer.AOP;

 

namespace Wayfarer.AOPSample

{

    /// <summary>

    /// Summary description for LogAOPSink.

    /// </summary>

    public class LogAOPSink:AOPSink

    {

         public LogAOPSink(IMessageSink nextSink):base(nextSink)

         {

            

         }

 

         protected override void AddAllBeforeAOPHandles()

         {

              AddBeforeAOPHandle("ADD",new BeforeAOPHandle(Before_Log));

             AddBeforeAOPHandle("SUBSTRACT",new BeforeAOPHandle(Before_Log));

         }

 

         protected override void AddAllAfterAOPHandles()

         {

             AddAfterAOPHandle("ADD",new AfterAOPHandle(After_Log));

             AddAfterAOPHandle("SUBSTRACT",new AfterAOPHandle(After_Log));

         }

 

         private void Before_Log(IMethodCallMessage callMsg)

         {           

             if (callMsg == null)

             {

                  return;

             }           

                       Console.WriteLine("{0}({1},{2})",callMsg.MethodName,callMsg.GetArg(0),callMsg.GetArg(1));

         }

 

         private void After_Log(IMethodReturnMessage replyMsg)

         {           

             if (replyMsg == null)

             {

                  return;

             }           

             Console.WriteLine("Result is {0}",replyMsg.ReturnValue);         

         }

 

    }

}

 

LogAOPProperty.cs

using System;

using Wayfarer.AOP;

using System.Runtime.Remoting.Messaging;

 

namespace Wayfarer.AOPSample

{

    /// <summary>

    /// Summary description for LogAOPProperty.

    /// </summary>

    public class LogAOPProperty:AOPProperty

    {

         protected override IMessageSink CreateSink(IMessageSink nextSink)

         {

             return new LogAOPSink(nextSink);

         }

 

         protected override string GetName()

         {

             return "LogAOP";

         }

    }

}

LogAOPAttribute.cs:

using System;

using System.Runtime.Remoting.Activation;

using System.Runtime.Remoting.Contexts;

using Wayfarer.AOP;

 

namespace Wayfarer.AOPSample

{

    /// <summary>

    /// Summary description for LogAOPAttribute.

    /// </summary>

    [AttributeUsage(AttributeTargets.Class)]

    public class LogAOPAttribute:AOPAttribute

    {

         protected override AOPProperty GetAOPProperty()

         {

             return new LogAOPProperty();

         }

   

    }

}

 

然后再定义监测aspect

MonitorAOPSink.cs

using System;

using System.Runtime.Remoting.Messaging;

using Wayfarer.AOP;

 

namespace Wayfarer.AOPSample

{

    /// <summary>

    /// Summary description for MonitorAOPSink.

    /// </summary>

    public class MonitorAOPSink:AOPSink

    {

         public MonitorAOPSink(IMessageSink nextSink):base(nextSink)

         {

            

         }

 

         protected override void AddAllBeforeAOPHandles()

         {

             AddBeforeAOPHandle("ADD",new BeforeAOPHandle(Before_Monitor));

             AddBeforeAOPHandle("SUBSTRACT",new BeforeAOPHandle(Before_Monitor));

         }

         protected override void AddAllAfterAOPHandles()

         {

             AddAfterAOPHandle("ADD",new AfterAOPHandle(After_Monitor));

             AddAfterAOPHandle("SUBSTRACT",new AfterAOPHandle(After_Monitor));

         }

 

         private void Before_Monitor(IMethodCallMessage callMsg)

         {           

             if (callMsg == null)

             {

                  return;

             }

             Console.WriteLine("Before {0} at {1}",callMsg.MethodName,DateTime.Now);

         }

         private void After_Monitor(IMethodReturnMessage replyMsg)

         {           

             if (replyMsg == null)

             {

                  return;

             }

             Console.WriteLine("After {0} at {1}",replyMsg.MethodName,DateTime.Now);

         }

    }

}

MonitorAOPProperty.cs

using System;

using Wayfarer.AOP;

using System.Runtime.Remoting.Messaging;

 

namespace Wayfarer.AOPSample

{

    /// <summary>

    /// Summary description for MonitorAOPProperty.

    /// </summary>

    public class MonitorAOPProperty:AOPProperty

    {

         public MonitorAOPProperty()

         {

             //

             // TODO: Add constructor logic here

             //

         }

 

         protected override IMessageSink CreateSink(IMessageSink nextSink)

         {

             return new MonitorAOPSink(nextSink);

         }

 

         protected override string GetName()

         {

             return "MonitorAOP";

         }

    }

}

MonitorAOPAttribute.cs

using System;

using System.Runtime.Remoting.Activation;

using System.Runtime.Remoting.Contexts;

using Wayfarer.AOP;

 

namespace Wayfarer.AOPSample

{

    /// <summary>

    /// Summary description for MonitorAOPAttribute.

    /// </summary>

    [AttributeUsage(AttributeTargets.Class)]

    public class MonitorAOPAttribute:AOPAttribute

    {

         protected override AOPProperty GetAOPProperty()

         {

             return new MonitorAOPProperty();

         }

    }

}

注意在这两个方面中,各自的PropertyName必须是唯一的。

现在,可以定义计算器类。

Calculator.cs

using System;

namespace Wayfarer.AOPSample

{

    /// <summary>

    /// Summary description for Calculator.

    /// </summary>

    [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;

         }

    }

}

需要注意的是Calculator类必须继承ContextBoundObject类。

最后,我们写一个控制台程序来执行Calculator

Program.cs:

using System;

namespace Wayfarer.AOPSample

{

    /// <summary>

    /// Summary description for Class1.

    /// </summary>

    class Program

    {

         /// <summary>

         /// The main entry point for the application.

         /// </summary>

         [STAThread]

         static void Main (string[] args)

         {

             Calculator cal = new Calculator();

             cal.Add(3,5);

             cal.Substract(3,5);

             Console.ReadLine();

         }

    }

}

运行结果如下:

六、结论

.Net平台下采用动态代理技术实现AOP,其原理并不复杂,而.Net Framework也提供了足够的技术来实现它。如果再结合好的设计模式,提供一个基本的AOP框架,将大大地简化开发人员处理“aspect”的工作。当然,本文虽然提供了实现AOP的实例,但其架构的设计还远远不能达到企业级的要求,如在稳定性、可扩展性上还需经过进一步的测试与改善。例如我们可以通过配置文件的形式,来配置方法与方面之间的映射。同时,由于采用了动态代理,在性能上还期待改进。

 

使用动态代理技术实现AOP,对实现AOP的类有一个限制,就是必须派生于ContextBoundObject类,这对于单继承语言来说,确实是一个比较致命的缺陷。所谓“仁者见仁,智者见智”,这就需要根据项目的情况,做出正确的抉择了。

 

参考:

1、 JGTM,《A Taste of AOP from Solving Problems with OOP and Design Patterns

2、 NiWalker,《Attribute.Net编程的应用》

3、板桥里人,《AOP与权限控制实现》

在《在.Net中关于AOP的实现》我通过动态代理的技术,基本上实现了AOP的几个技术要素,包括aspectadvicepointcut。在文末我提到采用配置文件方式,来获取advicepointcut之间的映射,从而使得构建aspect具有扩展性。

细细思考这个问题,我发现使用delegate来构建advice,似乎并非一个明智的选择。我在建立映射关系时,是将要拦截的方法名和拦截需要实现的aspect逻辑建立一个对应关系,而该aspect逻辑确实可以通过delegate,使其指向一族方法签名与该委托完全匹配的方法。这使得advice能够抽象化,以便于具体实现的扩展。然而,委托其实现毕竟是面向过程的范畴,虽然在.Net下,delegate本身仍是一个类对象,然而在创建具体的委托实例时,仍然很难通过配置文件和反射技术来获得。

 

考虑到委托具有的接口抽象的本质,也许采用接口的方式来取代委托更为可行。在之前的实现方案中,我为advice定义了两个委托:

public delegate void BeforeAOPHandle(IMethodCallMessage callMsg);

public delegate void AfterAOPHandle(IMethodReturnMessage replyMsg);

 

我可以定义两个接口IBeforeAction和IAfterAction,分别与这两个委托相对应:

    public interface IBeforeAdvice

    {

        void BeforeAdvice(IMethodCallMessage callMsg);

}

    public interface IAfterAdvice

    {

        void AfterAdvice(IMethodReturnMessage returnMsg);

}

通过定义的接口,可以将AdviceAspect分离开来,这也完全符合OO思想中的“责任分离”原则。

(注:为什么要为Advice定义两个接口?这是考虑到有些Aspect只需要提供BeforeAfter两个逻辑之一,如权限控制,就只需要before Action。)

 

那么当类库使用者,要定义自己的Aspect时,就可以定义具体的Advice类,来实现这两个接口,以及具体的Advice逻辑了。例如,之前提到的日志Aspect

    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

}

 

而在AOPSink类的派生类中,添加方法名与Advice映射关系(此映射关系,我们即可理解为AOPpointcut)时,就可以添加实现了Advice接口的类对象,如:

         public override void AddAllBeforeAdvices()

         {

            AddBeforeAdvice("ADD",new LogAdvice());

            AddBeforeAdvice("SUBSTRACT", new LogAdvice());

         }

         public override void AddAllAfterAdvices()

         {

             AddAfterAdvice("ADD",new LogAdvice());

            AddAfterAdvice("SUBSTRACT", new LogAdvice());

         }

由于LogAdvice类实现了接口IBeforeAdviceIAfterAdvice,因此诸如new LogAdvice的操作均可以通过反射来创建该实例,如:

IBeforeAdvice beforeAdvice =

(IBeforeAdvice)Activator.CreateInstance("Wayfarer.AOPSample","Wayfarer.AOPSample.LogAdvice").Unwrap();

CreateInstance()方法的参数值,是完全可以通过配置文件来配置的:

<aop>

    <aspect value ="LOG">

         <advice type="before" assembly="Wayfarer.AOPSample" class="Wayfarer.AOPSample.LogAdvice">

             <pointcut>ADD</pointcut>

             <pointcut>SUBSTRACT</pointcut>

         </advice>

         <advice type="after" assembly="Wayfarer.AOPSample" class="Wayfarer.AOPSample.LogAdvice">

             <pointcut>ADD</pointcut>

             <pointcut>SUBSTRACT</pointcut>

         </advice>

    </aspect>   

</aop>

这无疑改善了AOP实现的扩展性。

 

《在.Net中关于AOP的实现》实现AOP的方案,要求包含被拦截方法的类必须继承ContextBoundObject。这是一个比较大的限制。不仅如此,ContextBoundObject对程序的性能也有极大的影响。我们可以做一个小测试。定义两个类,其中一个类继承ContextBoundObject。它们都实现了一个累加的操作:

class NormalObject

    {

        public void Sum(int n)

        {

            int sum = 0;

            for (int i = 1; i <= n; i++)

            {

                sum += i;

            }

            Console.WriteLine("The result is {0}",sum);

            Thread.Sleep(10);

        }

    }

 

    class MarshalObject:ContextBoundObject

    {

        public void Sum(int n)

        {

            int sum = 0;

            for (int i = 1; i <= n; i++)

            {

                sum += i;

            }

            Console.WriteLine("The result is {0}", sum);

            Thread.Sleep(10);

        }

    }

然后执行这两个类的Sum()方法,测试其性能:

    class Program

    {

        static void Main (string[] args)

        {

            long normalObjMs, marshalObjMs;

            Stopwatch watch = new Stopwatch();

            NormalObject no = new NormalObject();

            MarshalObject mo = new MarshalObject();

 

            watch.Start();

            no.Sum(1000000);

            watch.Stop();

            normalObjMs = watch.ElapsedMilliseconds;

            watch.Reset();

 

            watch.Start();

            mo.Sum(1000000);

            watch.Stop();

            marshalObjMs = watch.ElapsedMilliseconds;

            watch.Reset();

 

            Console.WriteLine("The normal object consume {0} milliseconds.",normalObjMs);

            Console.WriteLine("The contextbound object consume {0} milliseconds.",marshalObjMs);           

            Console.ReadLine();

        }

    }

得到的结果如下:

从性能的差异看,两者之间的差距是比较大的。如果将其应用在企业级的复杂逻辑上,这种区别就非常明显了,对系统带来的影响也是非常巨大的。

 

另外,在《在.Net中关于AOP的实现》文章后,有朋友发表了很多中肯的意见。其中有人提到了AOPAttribute继承ContextAttribute的问题。评论中提及微软在以后的版本中,不再提供ContextAttribute。如果真是如此,确有必要放弃继承ContextAttribute的形式。不过,在.Net中,除了ContextAttribute之外,还提供有一个接口IContextAttribute,该接口的定义为:

public interface IContextAttribute

{

        void GetPropertiesForNewContext(IConstructionCallMessage msg);

        bool IsContextOK(Context ctx, IConstructionCallMessage msg);       

}

此时只需要将原来的AOPAttribute实现该接口即可:

    public abstract class AOPAttribute:Attribute,IContextAttribute//ContextAttribute

    {

        #region IContextAttribute Members

        public void GetPropertiesForNewContext(IConstructionCallMessage ctorMsg)

        {

            AOPProperty property = GetAOPProperty();

            property.AspectXml = m_AspectXml;

            property.AspectXmlFlag = m_AspectXmlFlag;

            ctorMsg.ContextProperties.Add(property);

        }

 

        public bool IsContextOK(Context ctx, IConstructionCallMessage ctorMsg)

        {

            return false;

        }

        #endregion

}

不知道,IContextAttribute似乎也会在未来的版本中被取消呢?

 

然而,从总体来看,这种使用ContextBoundObject的方式是不太理想的,也许它只能停留在实验室阶段,或许期待微软在未来的版本中得到更好的解决!?

 

当然,如果采用CastleDynamicProxy技术,可以突破必须继承CotextBoundObject的局限,但随着而来的局限却是AOP拦截的方法,要求必须是virtual的。坦白说,这样的限制,不过与前者乃“五十步笑百步”的区别而已。我还是期待有更好的解决方案。

 

说到AOP的几大要素,在这里可以补充说说,它主要包括:

1Cross-cutting concern

 

  在OO模型中,虽然大部份的类只有单一的、特定的功能,但它们通常会与其他类有着共同的第二需求。例如,当线程进入或离开某个方法时,我们可能既要在数据访问层的类中记录日志,又要在UI层的类中记录日志。虽然每个类的基本功能极然不同,但用来满足第二需求的代码却基本相同。

 

2Advice

 

  它是指想要应用到现有模型的附加代码。例如在《在.Net中关于AOP的实现》的例子中,是指关于打印日志的逻辑代码。

 

3Point-cut

 

  这个术语是指应用程序中的一个执行点,在这个执行点上需要采用前面的cross-cutting concern。如例子中,执行Add()方法时出现一个Point-cut,当方法执行完毕,离开方法时又出现另一个Point-cut

 

4Aspect

 

Point-cutadvice结合在一起就叫做aspect。如例子中的LogMonitor。在对本例的重构中,我已经AOPSink更名为Aspect,相应的LogAOPSinkMonitorAOPSink也更名为LogAspectMonitorAspect

 

以上提到的PointCutAdviceAOP技术中,通常称为动态横切技术。与之相对应的,是较少被提及的静态横切。它与动态横切的区别在于它并不修改一个给定对象的执行行为,相反,它允许通过引入附加的方法属性和字段来修改对象固有的结构。在很多AOP实现中,将静态横切称为introduce或者mixin

 

在开发应用系统时,如果需要在不修改原有代码的前提下,引入第三方产品和API库,静态横切技术是有很大的用武之地的。从这一点来看,它有点类似于设计模式中提到的Adapter模式需要达到的目标。不过,看起来静态横切技术应比Adapter模式更加灵活和功能强大。

 

例如,一个已经实现了收发邮件的类Mail。然而它并没有实现地址验证的功能。现在第三方提供了验证功能的接口IValidatable

public interface IValidatable

{

    bool ValidateAddress();

}

如果没有AOP,采用设计模式的方式,在不改变Mail类的前提下,可以通过Adapter模式,引入MailAdater,继承Mail类,同时实现IValidatable接口。采用introduce技术,却更容易实现该功能的扩展,我们只需要定义aspect:(注:java代码,使用了AspectJ

import com.acme.validate.Validatable;

 

public aspect EmailValidateAspect

{

   declare parents: Email implements IValidatable;

 

   public boolean Email.validateAddress(){

     if(this.getToAddress() != null){

          return true;

     }else{

          return false;

     }

   }

}

 

从上可以看到,通过EmailValidateAspect方面,为Emailintroduce了新的方法ValidateAddress()。非常容易的就完成了Email的扩展。

 

我们可以比较一下,如果采用Adapter模式,原有的Email类是不能被显示转换为IValidatable接口的,也即是说如下的代码是不可行的:

Email mail = new Email();

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

要调用ValidateAddress()方法,必须通过EmailAdapter类。然而通过静态横切技术,上面的代码就完全可行了。

 

静态横切的技术在企业应用上还需要进一步验证和测试,不过遗憾的是,《在.Net中关于AOP的实现》一文采用的动态代理技术,是无法完成实现静态横切的目标的。



使用decj简化Web前端开发
Web开发框架形成之旅
更有效率的使用Visual Studio
MVP+WCF+三层结构搭建框架
ASP.NET运行机制浅析【图解】
编写更好的C#代码
10个Visual Studio开发调试技巧
更多...   


.NET框架与分布式应用架构设计
.NET & WPF & WCF应用开发
UML&.Net架构设计
COM组件开发
.Net应用开发
InstallShield


日照港 .NET Framework & WCF应用开发
神华信息 .NET单元测试
北京 .Net应用软件系统架构
台达电子 .NET程序设计与开发
赛门铁克 C#与.NET架构设计
广东核电 .Net应用系统架构
更多...   
 
 
 
 
 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号