为什么要使用后编译器？

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文档。您有更好的解决方案吗？恐怕你不知道。经典的代码生成器没有帮助。函数式编程（委托）？它在某些方面工作得相当好，但在这里不行：您需要将方法参数传递给模式。那么还剩下什么呢？用自然语言描述模式并相信开发人员会实现它们。

会发生什么？

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

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

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

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

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

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

因此，如果将所有这些放在一起：

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

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

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

Answer 2

假设您已经有一个设计良好、经过良好测试等的类。您希望轻松地在某些方法上添加一些计时。是的，您可以使用依赖注入，创建一个装饰器类，它代理原始的但每个方法都有时间 - 但即使该类也将是一团重复......

或者您可以添加反射到混合中并使用某种描述的动态代理，它允许您编写一次计时代码，但要求您获得正确的反射代码 - 这并不像想象的那么容易，特别是在涉及泛型的情况下。

...或者您可以向每个想要计时的方法添加一个属性，编写一次计时代码，并将其作为编译后步骤应用。

我知道哪个对我来说更优雅 - 并且在阅读代码时更明显。即使在 DI 不合适的情况下（它确实不适合系统中的每个类）并且其他地方没有其他更改，它也可以应用。

Answer 3

AOP (PostSharp) 用于从一个位置将代码附加到应用程序中的各种点，因此您不必将其放置在那里。

您无法实现 PostSharp 使用 Reflection 所做的事情。

我个人认为它在生产系统中没有太大用处，因为大多数事情都可以通过其他更好的方式（日志记录等）来完成。

您可能想查看有关此问题的其他主题：

• 任何人都有 Postsharp 生产经验吗？< /a>
• 除了日志记录和事务管理之外AOP 有哪些实际应用？
• 面向方面编程：你用 PostSharp 做什么？
• 等（搜索）

Answer 4

方面拿走了所有的副本和内容。粘贴代码并加快添加新功能的速度。

例如，我最讨厌的就是不得不一遍又一遍地编写同一段代码。 Gael 在他的网站 (www.postsharp.net) 上有一个关于 INotifyPropertyChanged 的​​非常好的示例。

这正是 AOP 的用途。忘记技术细节，只需实现您所要求的即可。

从长远来看，我认为我们都应该告别现在编写软件的方式。编写样板代码并手动迭代是乏味且明显愚蠢的。

未来属于由面向对象框架结合在一起的声明式、函数式风格，以及由方面处理的横切关注点。

我想唯一不会很快得到它的人是那些仍然为代码行付费的人。