如果将面向方面的编程作为C＃语言的本地范例，我与同事进行了一些有趣的辩论，讨论其优点。
辩论似乎分为三个阵营：
那些认为C＃本身已经太复杂了的人，而AOP之类的另一个主要功能只会使情况更加混乱。
那些认为这将是一个很好的补充，因为可以在不破坏现有语言的前提下增加语言表达能力的任何事物都是一件好事。
那些认为没有必要的人是因为，诸如PostSharp之类的可以执行编译后IL编织的库已经以语言中立的方式允许了它。
我很好奇C＃/。NET开发人员社区的想法。
最佳答案
如果语言使开发和使用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实施语言。