什么时候执行AOP代码 [英] when is AOP code executed

问题描述

我已经阅读了一些有关AOP的文章，它看起来像是一个非常有趣且功能强大的工具.

I have read some articles about AOP and it looks like a very interesting and powerful tool.

那性能呢?

例如，如果我创建一个名为MyMethodAspect的方面属性，该怎么办.它将做一件简单的事情- 在具有该属性的方法的开头，称为MyMethodAspect类中包含的代码.例如，写一行文本-'starting ...'

For example, what if I create an aspect attribute called MyMethodAspect. It would do a simple thing - on the start of exucting method with that attribute is called a code contained in my MyMethodAspect class. For example write a line of text - 'starting...'

那是基本示例-但是如果启动该方法时执行的逻辑要困难得多. 我能理解，在启动该方法时执行的代码只被编译了一次，而之后AOP不需要任何额外的性能提升了吗?

thats the basic example - but what if the logic executed on starting the method is much more difficult. Can I understand it that the code executed on starting the method is compiled only once and than later the AOP wont need any additional performance power?

C#:

public void Do(int x){
Console.WriteLine(x);
}

我想象IL就像(差不多一样):

I imagine the IL is something like (pretty much the same):

 public void Do(int x){
    Console.WriteLine(x);
    }

并具有以下方面:

C#:

[MyMethodAspect]
    public void Do(int x){
    Console.WriteLine(x);
    }

所以我认为IL类似于:

so i suppose the IL is something like:

 public void Do(int x){
Console.WriteLine("starting...");
    Console.WriteLine(x);
    }

MyMethodAspect类是否仅在编译阶段才真正使用，以后又不需要任何其他性能?

Is the MyMethodAspect class really used only during compile phase and later it do not need any additional performace power?

我希望你能理解我的问题，这让我很难解释:)

I hope you can understand what my question is, its hard for me to explain :)

谢谢

推荐答案

让我们谈谈性能和AOP实现.

Let's talk about performance and AOP implementations.

AOP框架必须谨慎对待3个关键问题，以使其更快:

AOP Framework have to be carefully about 3 critical things to be faster :

• 启动时间(运行时初始化)
• 拦截技师
• 消费者整合

在名义上，除非拦截垃圾邮件重新启动应用程序，否则只有拦截机制和用户集成才是真正重要的.

in nominal usage, only interception mechanic and consumer integration are really important unless you spam restarting your application.

通常，在编译时工作的AOP框架没有任何启动时间，并且拦截机制类似于您实际上直接在代码中编写建议的方式.这就是为什么他们经常是高效率的人.

Usually an AOP Framework working at compile time does not have any fire time and interception mechanic is similar as you really write the advice directly in the code. That's why they are often efficients.

关于运行时AOP框架，它们通常并不是真正的AOP模式，因为它们需要代理/工厂模式来拦截方法调用.代理意味着两种类型的开销:包装或消息接收器.在第一种情况下，它是可以接受的，而在第二种情况下，它确实需要花费.

Concerning runtime AOP Framework, they are often not really AOP pattern because they need proxy/factory pattern to intercept method calls. Proxy means 2 types of overhead : wrapping or message sink. In the first case it is acceptable and for the second, it really cost.

对于使用者集成，编译时和运行时AOP都存在相同的问题:

Both compile time and runtime AOP have the same issue for the consumer integration :

• 装箱/拆箱
• 处理原始代码
• 定义建议的方式.

需要定义一个横向代码是合理的.

it is justified by the need to define a transversal code.

消费者集成代表了AOP框架的真正缺陷(性能问题).

The consumer integration represents the real pitfall (performance issue) of an AOP Framework.

编译时通常只需要管理这一点.这就是为什么大多数时候它们在性能方面会更好的原因.

Compile time has often only this point to manage. That's why most of time they are better in term of performance.

我之所以写通常"是因为它对于常见的实现是正确的.

I wrote "usually" because it is true for common implementations.

绝对而言，运行时AOP Framework可以做得更好，因为它在编织时可以具有更多信息.实现高效的运行时AOP框架要困难得多(不可能吗?)，因为它需要大量未公开的已知知识来操纵CLR.

In absolute, runtime AOP Framework can do better because it can have more informations while weaving. It is just harder (impossible?) to implement an efficient runtime AOP Framework because it requiered a lots of undocumented knownledge to manipulate the CLR.

经过大量研究，我开发了一种新的.NET运行时AOP框架样式，它可以打破规则. NConcern .NET AOP框架旨在通过提供独有的功能来提高效率(甚至比基于编译时间的效率更高).通过简单的委托，表达式和ILGenerator进行拦截机制(基于方法交换)和使用者集成，以避免装箱/拆箱和不必要的客户端使用准备.例如，大多数时候有必要使用反射来了解如何执行建议.许多AOP框架都对元数据进行了实际处理，这意味着通过准备元数据会有开销.在一个很好的实现中(例如NConcern提供)，您可以在实际处理之前获得这些信息，因为AOP框架为您提供了描述如何生成建议的方法，而不是直接使用反射和装箱对其进行编码.即使在NConcern的基本界面(直接建议定义)中，您也可以选择捕获或不捕获元数据.

After a lot of research, I developed a new style of .NET runtime AOP Framework which can break the rules. NConcern .NET AOP Framework is built to be efficient (even more than compile time based) by offering an exclusive interception mechanic (based on method swaping) and consumer integration by simple delegate, expression and ILGenerator to avoid boxing/unboxing and unecessary client usage preparation. For example, most of time it is necessary to use reflection to know how to execute the advice. A lot of AOP Framework give the metadata in real treatment, that means they have an overhead by preparing it. In a good implementation (like NConcern offer), you can have these informations before the real treatment because the AOP Framework offer you to describe how to generate Advice instead of coding it directly with reflection and boxing. Even in basic interface (direct advice definition) of NConcern you have choice to capture or not the metadata.

最后，请仔细考虑客户端AOP界面以定义您的建议，在大多数情况下，它代表实际的性能开销.

To conclude, be carefully about client AOP interface to define your advices, it represents most of case the real performance overhead.

这篇关于什么时候执行AOP代码的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！