2

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

4

6 回答 6

2

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

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

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

于 2009-05-22T13:29:53.897 回答
0

优点是，如果您决定更改如何调用脏标志逻辑的实现，您只需要进行一次更改（在 AOP 方法的主体中），而不是 N 次更改（将所有SetDirty调用替换为其他内容）。

于 2009-05-22T13:16:11.507 回答
0

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

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

于 2009-05-22T13:16:54.827 回答
0

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

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

AOP 让你的类保持干净，做他们应该做的事情，同时不理会其他部分。

于 2009-05-22T13:24:42.703 回答
0

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

于 2009-05-22T13:35:50.560 回答
0

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

于 2009-05-22T18:00:33.900 回答