面向方面的编程是否是C＃语言的积极补充？

Question

如果将面向方面编程作为C＃语言的原生范例，我与同事就一些优点进行了一些有趣的辩论。

辩论似乎分为三个阵营：

1. 那些认为C＃已经过于复杂的人，以及像AOP这样的另一个主要功能只能进一步混淆水域。
2. 那些认为这将是一个很好的补充的人，因为任何能够在不破坏现有情况的情况下提高语言表达能力的事情都是一件好事。
3. 那些不认为有必要的人，因为像PostSharp这样执行编译后IL编织的库已经允许它以语言中立的方式。

我很好奇C＃/ .NET开发人员的社区在想什么。

Answer 1

我同意第一个阵营。 C＃已经加载了功能。改为使用PostSharp库。

Answer 2

如果语言能够更容易开发和使用AOP扩展，那将是很棒的。

例如：

• 如果可以将委托（或匿名方法或lambda）作为参数提供给自定义属性，那就太好了。在C＃中实现它并不是很多工作，在CLR中实现它很容易（因为它支持类型，为什么不支持方法？）。它将允许以优雅的方式表达“切入点”。

• 支持'fieldof'和'methodof'。它受到CLR（带有错误）的支持，而不是C＃。 “eventof”和“propertyof”也是如此（他们目前在CLR中没有支持）。

• 更好的调试符号可以使方面编织者更容易报告错误消息并在代码中给出位置。

• 拥有模块化编译器会很棒;实现某些功能（例如基于方面和接口介绍的源代码生成）会更便宜。

那就是说，我不认为该语言应该提供AOP扩展。这太大了（我认为PostSharp 2.0比C＃编译器本身更复杂，至少比C＃2.0更复杂）。让我们面对现实：AOP仍然是实验性的，因为我们仍然不知道我们想从中得到什么。仍然没什么经验。但我们希望语言的规范是稳定的，并且要解决众所周知的问题（想象实体框架是语言的一部分）。

此外，有不同的方法来实现AOP，而构建时间只是其中之一。使用运行时技术没有什么不对，比如JIT发出的代理（Spring / Castle）;这些仅适用于不同的用例，并有各自的优缺点。

所以我的意见是赞成的：对于有限且定义明确的语言扩展，可以更容易地开发AOP框架;不能用语言完整的AOP实现。

Answer 3

这将是有用的，但许多用途都以各种方式包含在内。例如，我们将能够在.NET4中进行发布和预验证，这是在aspectJ中使用around的一种用法。

通过使用扩展方法，您可以将新方法注入到可能没有源代码的对象中。

并且，我不相信它会被广泛使用，因为C＃开发人员似乎以不同于Java程序员的方式处理问题，这很容易做到，因为现在这两种语言已经分歧了很多。

我不知道那些倾向于使用.NET的公司是否想要使用像AOP这样的东西，你需要工具来帮助理解注入哪些方面，例如Eclipse上的AJDT。