面向方面的编程会成为 C# 语言的积极补充吗？答案

【问题标题】：Would aspect oriented programming be a positive addition to the C# language?面向方面的编程会成为 C# 语言的积极补充吗？
【发布时间】：2009-10-21 18:37:51
【问题描述】：

我与同事就将面向方面编程作为 C# 语言的本机范例的优点进行了一些有趣的辩论。

辩论似乎分为三个阵营：

那些认为 C# 已经太复杂的人，像 AOP 这样的另一个主要特性只会使情况更加混乱。
那些认为这将是一个很好的补充，因为任何可以在不破坏现有语言的情况下增加语言表达力的东西都是一件好事。
那些认为没有必要的人，因为像 PostSharp 这样执行编译后 IL 编织的库已经允许它以一种语言中立的方式进行。

我很好奇 C#/.NET 开发人员社区的想法。

【问题讨论】：

标签： c# .net programming-languages aop

【解决方案1】：

如果语言能够更容易开发和使用 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 框架； no 用于该语言的完整 AOP 实现。

【讨论】：

关于 fieldof、methodof 等，您应该阅读 Eric Lippert 的这篇文章：blogs.msdn.com/ericlippert/archive/2009/05/21/…。顺便说一句，我怀疑 Eric 是否会同意这种说法：“在 C# 中实现它并不是很多工作”;)。据他说，即使是非常简单的功能也需要大量工作。
我不能同意这是主要工作。我可以理解任何小的工作都需要微软付出巨大的努力，这就是为什么我们能够以微软的一小部分成本开发出像 PostSharp 这样的复杂工具。而且我不同意他的论点，即我们不能用 methodof 做任何事情，也不能没有任何事情，因为唯一的选择是反射，而反射不抵抗混淆（不是说重构）。

【解决方案2】：

我同意第一个阵营。 C# 已经加载了许多特性。请改用PostSharp 库。

【讨论】：

根据我的经验，PostSharp 的功能非常有限，我没有看到使用它的意义，但后来我被 AspectJ 宠坏了。
一些问题：1) 将 AoP 集成到语言中（而不是使用像 PS 之类的库）会如何损害 C#？不想使用它的开发人员不会忽略它，那些愿意使用 PS 的开发人员在使用 PS 和学习语言功能方面需要学习的东西一样多。 2) 与事后添加的库相比，集成到平台 (CLR) 或语言 (C#) 中的实现不会更不容易破坏或引入问题吗？
@LBushkin：也可以提出完全相反的观点：添加到语言中的任何附加功能都会在编译器、运行时和/或框架工具集中引入更高级别的复杂性——甚至更难保持一切整洁、稳定、可维护、快速且易于优化。
...而且，为什么要谨慎考虑向语言添加新功能的最重要一点是：“一旦添加了功能，它就永远存在于语言中。” （埃里克·冈纳森，blogs.msdn.com/ericgu/archive/2004/01/12/57985.aspx）
@LBushkin - 将 AOP 添加到语言中的问题在于，您必须拥有让人们看到正在发生的事情的工具，这对于相对少数的人来说是很多工作。人们将投入生产。

【解决方案3】：

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

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

而且，我不相信它会被广泛使用，因为 C# 开发人员处理问题的方式似乎与 Java 程序员不同，这很容易做到，因为这两种语言现在已经大相径庭了。

我不知道倾向于使用 .NET 的公司是否愿意使用 AOP 之类的东西，并且您需要一些工具来帮助了解哪些方面被注入到哪里，例如 Eclipse 上的 AJDT。

【讨论】：

PostSharp 2.0 现在有类似 AJDT for Visual Studio 的东西。
@Gael Fraiteur - 谢谢你的信息。我真正可以在 Java 中执行 AOP 的唯一方法是 AJDT，否则我不知道真正发生了什么。很高兴 PostSharp 2 有类似的东西。我发现自己对它不如 AspectJ 灵活这一事实感到沮丧，因此我找到了其他方法来做我正在尝试的事情，例如扩展方法。
而且 PostSharp 2.0 有建议甚至是伪装的切入点（尽管在 CTP1 中对切入点的支持非常有限）:)。
我将不得不看看 PostSharp 2.0，我可能会发现它比我尝试使用 PostSharp 1 时更有用