运行时AOP与编译时AOP [英] Run-time AOP vs Compile-time AOP

问题描述

这两种类型的AOP框架的优缺点是什么?我使用Unity作为我的aop框架，但我猜像postharp这样的编译时aop框架可能比运行时aop框架具有更好的性能?看起来运行时aop框架使用反射来实现注入.

What's the advantage and disadvantage of these two type of AOP framework? I'm using Unity as my aop framework, but I guess the compile-time aop framework such as postsharp may have better performance than run-time aop framework? It looks like run-time aop framework use reflection to implement the injection.

推荐答案

我不是.NET专家，但是我知道Java生态系统中的AOP世界，尤其是AspectJ和Spring AOP.基本上有4种方面的编织:

I am not a .NET guy, but I know the AOP world in the Java ecosystem, especially AspectJ and Spring AOP. Basically there are 4 types of aspect weaving:

• 源代码编织::方面代码作为源代码语句注入到您的应用程序源代码中.这是某种预处理器方法.如今，Java世界中没有AOP框架使用这种方法，但是在AOP的早期就曾经使用过这种方法.
  • 如果操作正确，这样做的好处是可以在运行时完全独立于任何运行时库或特殊的AOP编译器.
  • 缺点是源代码过大，并且在编译之前需要进行预处理/代码生成步骤.您将始终需要生成的源代码来进行调试.
  • Source code weaving: Aspect code is injected as source code statements into your application source code. This is some kind of preprocessor approach. No AOP framework in the Java world uses this approach nowadays, but there used to be some in the early days of AOP.
    • The advantage would be complete independence of any runtime libaries or special AOP compilers during runtime, if done right.
    • The disadvantage would be bloated source code and a preprocessing / code generation step before compilation. You would always need the generated source code for debugging.
    • 优点是方面编织没有运行时开销.您唯一需要的是类路径上的小型运行时库.
    • 缺点是，如果要将方面完全编织到应用程序中以供运行时使用，则无法推迟决策.但是，这仅是在处理调试或跟踪方面不需要的问题时才存在的问题.另一个缺点是，这种方法仅适用于您控制下的代码，即您需要拥有源代码.它不适用于第三方库.
    • 优点是它也适用于您没有源代码的第三方代码.这种方法也可以与编译时编织混合使用.您还可以避免加载时编织的开销(请参见下文).
    • 缺点类似于编译时编织:将方面编织到代码中后，您不能取消应用方面，仅通过诸如if()之类的切入点来停用其执行.但这可能非常有效.
    • The advantage is that it also works for 3rd party code you do not have the source code for. This approach can also be mixed with compile-time weaving. You also avoid the overhead of load-time weaving (see below).
    • The disadvantages are similar to compile-time weaving: You cannot unapply an aspect once it is woven into the code, merely deactivate its execution by pointcuts such as if(). But this can be quite efficient.
    • 优点是您可以动态决定是否编织.如果通过字节码转换而不是通过动态代理或反射完成(请参见下文)，则生成的字节码与通过编译时或二进制编织创建的字节码效率相同.另一个优点是，就像二进制编织一样，只要编织代理可以看到"它，它就可以在您自己的代码以及第三方代码中使用，即它发生在子类加载器中.
    • 缺点是在应用程序启动期间一次性编织开销，因为编织是在发生类加载时完成的.
    • 除了您选择的框架(例如Spring)碰巧支持它外，我没有想到任何特殊的优势.
    • 由于基于代理的方法，缺点是对公共，非静态方法和运行时开销的限制.它还不捕获内部方法调用，即当代理类调用其自身的方法之一时，因为代理服务器未捕获这些调用.不支持特殊类型的切入点，例如构造函数拦截，成员变量读/写访问以及更多其他切入点，这使其更像是"AOP精简版"方法.但这足以满足您的目的.

    通常，良好的方面编译器(例如AspectJ)会创建非常有效的字节码，并且在运行时不会严重依赖反射.如果您选择的方面框架确实依靠反射，则可能不是很快.但这也许足够快，这取决于您对方面的使用程度.

    Generally, good aspect compilers such as AspectJ create very efficient bytecode and do not heavily rely on reflection during runtime. If your aspect framework of choice does rely on reflection, probably it is not very fast. But maybe it is fast enough, depending on how heavily you use aspects.

    可能我已经写了太多，但我可以写更多.这就是为什么我现在要停下来.此外，这种问题不太适合StackOverflow，因为它可能导致哲学讨论和基于观点的辩论.我希望即使如此，我还是要做到客观/公正.

    Probably I have written too much already, but I could write even more. This is why I am stopping now. Besides, this kind of question is not well-suited to StackOverflow because it can lead to philosophical discussions and opinion-based debates. I hope I managed to be fairly objective/impartial even so.

    这篇关于运行时AOP与编译时AOP的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！