AOP 脏跟踪答案

【问题标题】：AOP Dirty TrackingAOP 脏跟踪
【发布时间】：2009-05-23 02:00:33
【问题描述】：

在过去，我使用了几种不同的方法对我的实体进行脏检查。我一直在考虑使用 AOP 在新项目中完成此操作的想法。这将要求我在我想要在设置属性时调用脏标志逻辑的类中的每个属性上添加一个属性。如果我必须为属性的每个属性添加一行额外的代码，那么仅在设置器中调用 SetDirty() 方法有什么好处。我想我在问使用 AOP 方法有什么优势（如果有的话）？

【问题讨论】：

标签： c# .net aop

【解决方案1】：

我想说，在这种情况下不仅没有任何优势：还有一点劣势。无论您调用 dirty() 还是使用 AOP，都使用相同数量的代码行，但就意图而言，仅调用 dirty() 更加简单明了。

老实说，我认为 AOP 有点超卖了。在读取代码方面，它增加了另一个级别的间接性，这通常不会有回报。

这里要考虑的关键是，它是否有助于下一个阅读本文的人（可能是几个月后的你）更快、更清楚地理解我想要做什么。如果您无法弄清楚这种不太直接的方法有什么更好的地方，那么您可能不应该使用它。（我是作为一名 Haskell 程序员这么说的，这意味着我自己并不反对非直截了当的方法。）

【讨论】：

【解决方案2】：

优点是如果您决定更改如何调用脏标志逻辑的实现，您只需要进行一次更改（在 AOP 方法的主体中），而不是 N 次更改（替换所有 SetDirty用别的东西打电话）。

【讨论】：

是的，但在 SetDirty 的情况下，可能的原因是什么？这样做可能节省的成本是否证明现在使用 AOP 增加的复杂性是合理的？
我同意你的一般观点，他使用的 AOP 框架似乎涉及很多属性开销。至于可能性有多大，鲍勃更适合做出这个决定。
是的，我知道，根据我对 SetDirty() 的看法和经验，我为什么提出这一点是不值得的。它带来了针对潜在变化的过度工程软件与针对您今天必须交付的工程的经典斗争。

【解决方案3】：

如果你必须用属性来装饰你的实体，我看不到任何好处。特别是如果您所做的只是调用一个方法。如果逻辑更复杂，那么我可以为使用 AOP 提出一个论据。

如果假设每次修改属性时都希望将其作为版本进行跟踪，这可能是可以注入的更复杂的行为，那么将其从属性中抽象出来可能是有益的。同时，您可能希望一次更改多个属性的版本，所以我回到那里并没有太大价值。

【讨论】：

【解决方案4】：

AOP 的使用是为了横切关注点。这意味着您希望拥有诸如日志记录、安全性等功能，但业务逻辑确实不属于您的课程。这可能用于脏标志逻辑，因为域对象不应该关心它已被更改。这取决于您的 DirtyLogicUtility 或它的名称。

例如，您希望在每次调用方法时记录，您可以将其放置在每个函数中，但稍后您希望有逻辑，以便在每个其他调用时记录它。

AOP 让你的类保持整洁，做他们应该做的事情，而让其他部分不理会。

【讨论】：

取决于你如何看待它。数据归域对象所有，因此跟踪更改只能由域对象完成，因为没有其他对象可以访问数据，域对象可以（因为它拥有它）：打开/关闭原则。

【解决方案5】：

一些 AOP 实现，特别是 PostSharp，允许您在程序集级别应用属性，并使用通配符确定它适用于哪些类。

【讨论】：

那将是一个节省，我正在使用 postsharp。我可以只在类级别应用该属性吗？我马上就会去。
嗯，我认为你可以，但我不知道如何。我知道您可以在类级别应用属性，并且当应用属性时，我相信您可以拦截单个属性和方法。 PostSharp有一个论坛，也许你可以在那里询问如何实现它。

【解决方案6】：

为什么您希望脏检查由实体负责？您可以在其他地方进行管理。该模式称为Unit of work

【讨论】：