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 :

• fire-time(运行时初始化)
• 拦截技师
• 消费者整合

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

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框架可以做得更好，因为它可以在编织的同时拥有更多的信息.实现高效的运行时 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 offer)，你可以在真正的处理之前获得这些信息，因为 AOP 框架让你描述如何生成 Advice，而不是直接用反射和装箱编码.即使在 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屋！