.Net 中 AOP 的最佳实现是啥？ [关闭]

Posted 2023-03-10

【中文标题】.Net 中 AOP 的最佳实现是啥？ [关闭]

【英文标题】：What is the best implementation for AOP in .Net? [closed].Net 中 AOP 的最佳实现是什么？ [关闭]

【发布时间】：2010-10-12 15:12:09

【问题描述】：

在 C#、VB.net 中有很多 AOP 实现。这是一些 AOP 实现：

PostSharp Castle DynamicProxy LinFu LOOM.NET Aspect.NET Enterprise Library 3.0 Policy Injection Application Block AspectDNG DotSpect (.SPECT) Spring.NET 框架作为其功能的一部分 Wicca 和 Phx.Morph An exhaustive analysis on AOSD solutions for .NET 可从特温特大学获得 Seasar.NET Aspect# Puzzle.NAspect 撰写* 设定点 NConcern .NET AOP Framework ...

.Net 中 AOP 的最佳实现是什么？我应该使用什么？

【问题讨论】：

如果您提供所有 AOP 的链接会很有帮助，这样可以为读者节省一点使用 Google 的时间。我希望这个问题/答案将成为 .NET 中不同 AOP 选项的一个很好的总结

52 人投票认为这是一个建设性的问题。 5 票投了它不是建设性的。谁决定的？至少版主应该改变或重新提出问题，但他们最好考虑大多数人的意见。

@Revious 完全同意！

令人惊讶的是，SO 和人们将这样的问题视为 OT。如此有用的问题和技术来讨论和帮助社区被简单地否决并关闭，但一群老式的 80 年代风格的人被困在过去。所以，世界变了。您想帮助回答特定问题，但至少在您的“封闭”标签中提供一个链接来发布此类问题，这是完全可以理解的。这将有很大帮助并避免这种愚蠢。

【参考方案1】：

如果动态拦截可以满足您的需求，我认为Castle Dynamic Proxy 是首选的解决方案。许多其他希望提供 AOP 功能的框架在内部使用该框架。通常，大多数现有的 IoC 容器现在都提供了一些动态拦截机制（Spring.NET、Castle Windsor、StructureMap 等）。如果您已经在使用 IoC 容器，那么查看它的提议可能会更容易。

如果动态拦截不能满足你的需求（编织密封类、拦截非虚调用等），那你肯定要静态编织。 PostSharp 是此域中的引用。

请注意，它还存在 Linfu，可用于利用两种 AOP 方式。

【讨论】：

+1 如果你想做运行时 AOP。如果您想要编译后 AOP，请在 PostSharp 上 +1

这个答案有什么更新吗？或者这仍然有效吗？我特别想知道 Spring.Aop 与 Castle 和 PostSharp 相比如何

很遗憾，PostSharp 是一种商业产品

Postsharp 是商业产品，不是免费的。请就静态编织提出其他建议。

@ShivamSachan 仅仅因为免费的东西并不能使它变得更好。 .net 中的大多数免费 AOP 在 2 到 5 年前的最后一次更新中消失了，PostSharp 仍然是同类中最好的。

【参考方案2】：

“最佳”是主观的。

首先，列出您需要的功能、架构等。然后寻找满足您需要的选项，而不会引入不必要的复杂性。例如，有几个是面向接口的：你的代码当前是面向接口的吗？如果没有，PostSharp 可能是更好的选择（被编织到原始类中）。但当然，PostSharp 不能在运行时配置……课程的马。

【讨论】：

您可以重新表述您所说的内容，如下所示：“最好是主观的，我会为这个框架的某些部分制定一个优缺点列表”。

【参考方案3】：

在 .NET 中进行面向方面编程的最佳方法是使用众所周知的设计技术。例如，通过应用SOLID principles，您可以获得允许添加横切关注点所需的灵活性和模块化。如果你有正确的设计，你甚至可以在没有任何框架的情况下应用大多数横切关注点。认为 OOP 不适合做 AOP 是一种谬误。

这里有一些提示：

不依赖具体实例，而是依赖抽象。 不要在同一个类中混用横切关注点和业务逻辑。 通过在实现这些关注点的类中包装具有业务逻辑的类来添加横切关注点 (decorators)。 在您的设计中找到常见的工件并对其建模，最好使用相同类型的抽象。以this 和this 为例。

当您拥有正确的抽象时，向系统添加新的横切关注点只需编写一个新的装饰器类并将其包装在正确的实现中即可。如果抽象是通用的，您可以将单个装饰器包装在一大组类中（这正是 AOP 的意义所在）。

虽然动态代理和代码编织等技术可以更轻松地处理设计不佳的应用程序，但对于好的设计来说，确实没有其他选择。迟早你会被烧死。这并不意味着不应该使用动态代理生成和代码编织。但是，如果没有适当的应用程序设计，即使这些技术也只会起到一点作用。

【讨论】：

AOP 是下一层抽象。事实上，正是继承和组合的限制导致了 AOP。你见过 Entlib 异常块吗？ Aspect 比每次调用数据库时都调用那个该死的块要干净得多，只是为了 try-catch-log-throw。

如果你用异常块包装对数据库的每次调用，那么无论如何你都做错了。它回到了良好的设计。总是。

那么正确的方法是什么而不是捕获数据库异常？

@OutOFTouch：看看this SO question的答案。

@SleeperSmith：虽然我不确定“AOP 是下一个抽象级别”是什么意思，但我确实认为如果不使用 AOP，就无法保持大型系统的可维护性。我相信应用 AOP。然而，AOP 是一种范式；不是工具。我同意继承的限制，但这并不是导致 AOP 的组合限制。缺乏适当的设计导致使用代码编织和动态代理工具。我使用装饰器应用横切关注点。这是我应用 AOP 的首选方式。

【参考方案4】：

我不知道最好，有很多框架，一天中没有足够的时间来尝试所有这些。

我确实使用过 PostSharp，并且对它上手如此简单感到惊喜。

我还研究了 Castle Windsor 和 Spring.Net 的 AOP，方法不同（运行时与编译时）。混合 AOP 和 IoC 似乎是有道理的。如果您还没有使用这些框架之一，则需要做更多的工作才能开始，但不要让这阻止您。

现在对于新项目，我可能会使用 Castle Windsor，但这主要是因为我还想使用 IoC。如果我必须在现有代码库中快速实现 AOP，我会使用 PostSharp。

【参考方案5】：

还有来自 Microsoft 的 Policy Injection 和 Unity Interception。