AOP Dirty Tracking

Question

In the past I have used a few different methods for doing dirty checking on my entities. I have been entertaining the idea of using AOP to accomplish this on a new a project. This would require me to add an attribute on every proptery in my classes where I want to invoke the dirty flag logic when the property is set. If I have to add an extra line of code to each property for the attribture, what is the benefit over just calling a SetDirty() method in the setters. I guess I am asking what would be the advantage, if any, of using the AOP approach?

Answer 1

The advantage is that should you decide to change the implementation of how to invoke the dirty flag logic, you'll only need to make one change (in the AOP method's body), not N changes (replacing all your SetDirty calls with something else).

Answer 2

I don't see any benefit if you have to decorate your entities with an attribute. Espeically if all your doing is calling a single method. If the logic was more complex then I could make an argument for using AOP.

If let's say each time you modify a property you wanted to track that change as a version, this might be more complex behavior that could be injected, then having this abstracted out of the property could be beneficul. At the same point you would probally want to version changing several properties at once so I come back to there not being much value.

Answer 3

The use of AOP is for cross cutting concerns. This means that you want to have a feature such as logging, security, ect but the business logic really does not belong in your class. This could be for the Dirty flag logic as the Domain object should not care that it has been changed. That is up to your DirtyLogicUtility or what ever name it has.

For example you want to log every time a method gets called for every you could place this in every function, but later on you want to have logic so that it is logged on every other call.

AOP keeps your classes clean doing what they are supposed to do while leaving the other pieces alone.

Answer 4

I'd say that not only is there not any advantage in this case: there's a bit of a disadvantage. You're using the same number of lines of code whether you call dirty() or you use AOP, but just calling dirty() is more simple and clear, as far as intent goes.

AOP, honestly, is a bit oversold, I think. It adds another level of indirection, in terms of reading the code, that often it doesn't pay back.

The key thing to think about here is, does it help the next guy reading this (which may be you a few months down the road) understand more quickly and clearly what I'm trying to do. If you have trouble figuring out what's better about the less straightforward approach, you probably shouldn't be using it. (And I say this as a Haskell programmer, which means I'm far from adverse to non-straightforward approaches myself.)

Answer 5

Some AOP implementations, specifically PostSharp, allow you to apply the attribute at an Assembly level with wildcards as to which classes it applies to.

Answer 6

Why do you want the dirty check to be the responsibility of the entities? You can manage this somewhere else. The pattern is called Unit of work