c# - Microsoft 是否正在开发 C# 中的 AOP 解决方案？

Question

Microsoft 是否正在开发 C# 中的 AOP 解决方案？什么是（真正的 AOP）替代方案？

额外的问题：代码契约是一种 AOP 吗？

Answer 1

PostSharp是另一种选择。易于上手，尽管它不再完全免费使用。

我不知道微软是否还在积极为Unity项目做出贡献。也许其他人可以对此有所了解。

代码契约不是（一种）面向方面的编程。

Answer 2

.net 中的大多数依赖注入框架都能够使用 AOP 技术，我个人更喜欢 Ninject 和 Interceptor 插件，因为它易于使用，并且不需要任何具有 3rd 方属性或任何东西的类污染。

话虽如此，Spring.net、Castle Windsor 和许多其他 DI 框架都支持相同的原理，但语法和方法略有不同，有些是 xml 驱动的，有些是 c# 驱动的，因此您可以获得编译时安全性。

需要考虑的一件事是，大多数 DI 框架通过类代理来做到这一点，因此它们要求您的方法是虚拟的，然后在运行时代理您的类方法，您可以在此时拦截。还有一些其他方法，例如 PostSharp 所做的 IL 编织，它可以比代理更快，尽管我没有任何测量来支持它。

没有看到额外的问题，对我来说，我想说这不是一个明确的答案，因为这取决于你如何使用它，因为通常你使用 AOP 作为一种分离非功能性问题的方式，例如日志记录、事务也许从您的源代码进行验证，因此您从外部添加此逻辑，因此理想情况下您的源代码不知道 AOP 发生（尽管如果您使用一些将耦合您的源代码的第 3 方属性，情况并非总是如此到 AOP 框架）。

由于代码契约可以与现有类内联编写或通过属性挂钩，或者我相信可以在运行时完全注入，就像日志记录问题一样，您可以将它们全部放入您的类中，但是当使用 AOP 方法时，您不会. 所以对我来说，代码契约只是一个强制执行某些东西的工具，你可以以 AOP 方式使用它，或者你可以将它嵌入到你的代码中。

Answer 3

作为替代方案，您也可以使用Spring AOP

链接：http ://static.springsource.org/spring/docs/2.0.x/reference/aop.html

注意：我更喜欢 Unity