这两种AOP框架的优缺点是什么？我使用Unity作为我的aop框架，但我猜像postsharp这样的编译时aop框架可能比运行时aop框架有更好的性能？看起来运行时aop框架使用反射来实现注入。
我不是 .NET 人员，但我了解 Java 生态系统中的 AOP 世界，尤其是 AspectJ 和 Spring AOP。基本上有 4 种方面编织类型：
-
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.
- 如果做得正确的话，优点是在运行时完全独立于任何运行时库或特殊的 AOP 编译器。
- 缺点是源代码臃肿，并且编译前需要预处理/代码生成步骤。您始终需要生成的源代码进行调试。
-
Compile-time weaving: Aspect code is woven into your application by a special compiler.
- 优点是方面编织没有运行时开销。您唯一需要的是类路径上的一个小型运行时库。
- 缺点是，如果您想将各个方面编织到应用程序中，则无法将决定推迟到运行时。但这只是在处理并不总是需要的调试或跟踪方面时的问题。另一个缺点是这种方法仅适用于您控制下的代码，即您需要拥有源代码。它不适用于第 3 方库。
-
Binary weaving: Aspect code is woven into existing class files after compilation rather than during compilation.
- 优点是它也适用于您没有源代码的第三方代码。这种方法也可以与编译时编织混合使用。您还可以避免加载时编织的开销（见下文）。
- 缺点与编译时编织类似：一旦切面被编织到代码中，您就无法取消应用它，只能通过切入点停用其执行，例如
if()。但这可能非常有效。
-
Load-time weaving (LTW): A weaving agent/library is loaded early when your VM/container is started. It gets a configuration file with rules describing which aspects should be woven into which classes.
- 优点是您可以动态决定是否编织/编织什么。如果通过字节码转换而不是通过动态代理或反射（见下文）完成，则生成的字节码与通过编译时或二进制编织创建的字节码同样有效。另一个优点是，就像二进制编织一样，它适用于您自己的代码以及第三方代码，只要编织代理可以“看到”它，即它发生在子类加载器中。
- 缺点是应用程序启动期间的一次性编织开销，因为编织是在类加载发生时完成的。
-
Proxy-based LTW: This special LTW form is used by Spring AOP while AspectJ does the previous 3 forms listed above. It works by creating dynamic proxies (i.e. subclasses or interface implementations) for aspect targets.
- 除了您选择的框架（例如 Spring）碰巧支持它之外，我想不出任何特殊的优势。
- 缺点是由于基于代理的方法而限制了公共、非静态方法和运行时开销。它也不会捕获内部方法调用，即当代理类调用其自己的方法之一时，因为这些调用不会被代理捕获。不支持特殊类型的切入点，例如构造函数拦截、成员变量读/写访问等等，这使得这更像是一种“AOP lite”方法。但这足以满足您的目的。
一般来说，好的方面编译器（例如 AspectJ）会创建非常高效的字节码，并且在运行时不会严重依赖反射。如果您选择的方面框架确实依赖于反射，那么它可能不是很快。但也许它足够快，具体取决于您使用方面的程度。
也许我已经写得太多了，但我还可以写更多。这就是我现在停下来的原因。此外，这类问题不太适合 StackOverflow，因为它可能会引发哲学讨论和基于观点的辩论。即便如此，我希望我能够做到相当客观/公正。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
