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

问题描述

这两种AOP框架的优缺点是什么?我使用 Unity 作为我的 aop 框架，但我猜想像 postsharp 这样的编译时 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.
    • 优点是方面编织没有运行时开销.您唯一需要的是类路径上的一个小型运行时库.
    • 缺点是，如果您想将切面编织到您的应用程序中，则不能推迟到运行时做出决定.但这只是在处理不需要的调试或跟踪方面时的问题.另一个缺点是这种方法仅适用于您控制下的代码，即您需要拥有源代码.它不适用于 3rd 方库.
    • 优点是它也适用于您没有源代码的第 3 方代码.这种方法也可以与编译时编织混合使用.您还可以避免加载时编织的开销(见下文).
    • 缺点与编译时编织类似:一旦将方面编织到代码中，您就不能取消它的应用，只能通过诸如 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.
    • 优点是您可以动态决定是否编织/编织什么.如果通过字节码转换而不是通过动态代理或反射(见下文)完成，则生成的字节码与通过编译时或二进制编织创建的字节码同样有效.另一个优点是，就像二进制编织一样，它适用于您自己的代码以及第 3 方代码，只要编织代理可以看到"它，即它发生在子类加载器中.
    • 缺点是应用程序启动期间的一次性编织开销，因为编织是在发生类加载时完成的.
    • 除了您选择的框架(例如 Spring)恰好支持它之外，我想不出任何特殊优势.
    • 缺点是基于代理的方法限制了公共、非静态方法和运行时开销.它也不捕获内部方法调用，即当代理类调用其自己的方法之一时，因为代理未捕获这些调用.不支持特殊类型的切入点，例如构造函数拦截、成员变量读/写访问等等，这使其更像是一种AOP lite"方法.但这足以满足您的目的.

    通常，好的方面编译器(例如 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屋！