postsharp - 为什么要使用后编译器？

Question

我正在努力理解为什么要使用后编译器，例如 PostSharp ，是否需要？

我的理解是，它只是在原始代码中插入代码，那么为什么开发人员不自己编写代码呢？

我希望有人会说它更容易编写，因为您可以在方法上使用属性，然后不会使它们困惑的样板代码，但这可以使用 DI 或反射以及一些深思熟虑来完成，而无需后期编译器。我知道，既然我已经说过反射，那么性能大象现在将进入 - 但我不关心这里的相对性能，因为大多数场景的绝对性能微不足道(亚毫秒到毫秒)。

Answer 1

让我们尝试从架构角度来看待这个问题。假设您是一名建筑师(每个人都想成为一名建筑师；) 您需要将架构交付给您的团队: 一组选定的库、架构模式和设计模式。作为设计的一部分，您说:“我们将使用以下设计模式实现缓存:”

string key = string.Format("[{0}].MyMethod({1},{2})", this, param1, param2 );
T value;
if ( !cache.TryGetValue( key, out value ) )
{
   using ( cache.Lock(key) )
   {
      if (!cache.TryGetValue( key, out value ) )
      {
         // Do the real job here and store the value into variable 'value'.
         cache.Add( key, value );
      }
   }
}

这是进行跟踪的正确方法。开发人员将要实现该模式数千次，因此您需要编写一个漂亮的 Word 文档，告诉您希望如何实现该模式。是的，一个Word文档。您有更好的解决方案吗？恐怕你不知道。经典的代码生成器没有帮助。函数式编程(委托(delegate))？它在某些方面工作得相当好，但在这里不行:您需要将方法参数传递给模式。那么还剩下什么呢？用自然语言描述该模式并相信开发人员会实现它们。

会发生什么？

首先，一些初级开发人员会查看代码并告诉他们“嗯。两次缓存查找。有点无用。一次就足够了。” (这不是玩笑——请向 DNN 团队询问这个问题)。并且您的模式不再是线程安全的。

作为架构师，您如何确保正确应用该模式？单元测试？很公平，但是您很难通过这种方式检测到线程问题。代码审查？这也许就是解决方案。

现在，您决定改变什么模式？例如，您检测到缓存组件中的错误并决定使用您自己的？您要编辑数千个方法吗？这不仅仅是重构:如果新组件具有不同的语义怎么办？

如果您决定不再缓存某个方法怎么办？删除缓存代码有多困难？

AOP 解决方案(无论框架是什么)与纯代码相比具有以下优点:

1. 它减少了代码行数。
2. 它减少了组件之间的耦合，因此当您决定更改日志组件时不必更改太多内容(只需更新方面)，因此它提高了容量随着时间的推移，您的源代码可以满足新的需求。
3. 由于代码较少，因此给定功能集出现错误的可能性较低，因此 AOP 提高了代码质量。

所以如果你把它们放在一起:

方面降低了软件的开发成本和维护成本。

我有一个关于这个主题的 90 分钟演讲，您可以在 http://vimeo.com/2116491 观看。 .

再次强调，AOP 的架构优势与您选择的框架无关。框架之间的差异(也在本视频中讨论)主要影响您可以在代码中应用 AOP 的程度，这不是这个问题的重点。