|
Hi Simon - You have a typical case of (A) cross entity dependence and (B) aggregate entity.
I'm not sure I would address either in the ways you have proposed. The moment I saw you listening for changes to EntityAspect.EntityState deep in a base class I tuned out. "Hitting a bug with a sledge hammer" I thought. Maybe I'm just lazy. Permit me to proceed (theoretically ... I haven't actually written this out) in a different manner.
--- (A) ORDER TOTAL ---
What affects the Order Total?
- Adding a detail
- Removing a detail
- Changing a detail's quanity, price, discount, ???
Let's start with Add and Remove. Personally, because this is an Aggregate, I would channel all adding and removing of OrderDetails through the AggregateRoot. I would PREVENT any process from creating/deleting an OrderDetail independently. The best way to do that is in the public constructor of the OrderDetail. Make it throw an exception.
Alternatively, you could throw an exception when anyone tries to set the OrderDetail's parent Order or parent OrderId.
Order should sport AddDetail and RemoveDetail methods. Only Order has the ability to set the OrderDetail's parent OrderId (devise an internal method for the purpose).
Now that you've channeled adding / deleting through the Order, there is no problem ensuring that Order raises property changed for OrderTotal during detail add/delete.
Still want to ignore my advice? Well you can also arrange for the Order to listen to changes in its own OrderDetail collection. You will find that OrderDetailsProperty.GetValue(this) returns the RelatedEntityList<OrderDetail> which has a CollectionChanged event you can listen to. You should be able to hook this by writing your own Order default constructor. Haven't tried but should work.
On to OrderDetail changes.
On simple approach is to provide a RaiseOrderTotalChanged method on the Order. In the OrderDetail, you can override OnPropertyChanged and have it call RaiseOrderTotalChanged on its parent Order.
Interesting, I would expect this to fire when adding a detail to a parent Order. You might only have to worry about how to notify the Order when you remove a detail.
--- (B) A CHANGE TO ORDER DETAIL IS A CHANGE TO THE PARENT ORDER ---
"Order", in this example, is what is known as an "Aggregate root entity". The Order Aggregate in this example consists of Order and its OrderDetails. They are an "Aggregate" because we have several entity types in a common graph that are always treated as a single thing. An aggregate always has a root (Order) in this case; the other members of the aggregate (OrderDetail in this case) cannot exist apart from the root entity.
This fact, by the way, explains why Product is not in the Aggregate even though Product is clearly part of Order's extended object graph. A change to Product does not propagate to changes in all Orders of that product (at least not in our example Order management system).
I think its important to treat each Aggregate entity individually.
I would program for the Order Aggregate by itself. The pattern applies to other aggregates certainly. But I wouldn't drive the behavior we're discussing down to a base entity shared by all entities (except as noted below ... there is always an except :-) ).
You can dirty the Order the moment a Detail changes. There are reasons to do this; perhaps you want it reflected immediately in the UI. Perhaps you need to know if the Order permits changes to one of its details!
We already established a mechanism for the OrderDetail to notify its parent Order of changes. It might as well dirty the parent Order at the same time via the same call. As part of that call, it checks to see if the Order is in the Unchanged state; if it is, call Order.EntityAspect.SetModified() .
If you need to ensure that no one modifies a locked down detail, you should do this in a custom, pre-set ValidationRule, defined for all properties of the OrderDetail.
---
However, I would not rely exclusively on dirtying the Order when an OrderDetail changes. The user could undo the OrderDetail change in which case the Order may not be dirty. Or the user might call undo changes on the Order even though one of its details is still dirty. You want to be sure to have integrity and consistency at the moment of save. That's why I look to the EntityManager's SavingHandler.
You have one right? You should. That's the place to validate the entities you are about to save before attempting to save them to the database.
In the SavingHandler, I validate every entity scheduled for save. I do this by calling into each entity's ValidateForSave method. "But they don't have such a method" you protest. Indeed they don't. You should add it. It's a good BaseEntity method.
Arguments to the ValidateForSave method include the (a) list of entities to save, (b) an empty list of entities to add to that list, and (c) an empty list of entities to remove from that list [rarely needed].
Within the ValidateForSave, you can add any other related entity (entities) to lists (b) or (c).
Your saving handler, which is iterating over list (a), looks for (b) and (c) coming back from the validated entity and takes appropriate action to update list (a) before calling ValidateForSave on the next item.
The point of this is that the Detail checks to see if its parent Order is in list (a). If not, it dirties the order (as described above), and adds the dirtied parent Order to list (b).
Consequently, the SavingHandler will include the dirtied parent Order among its list of entities to save; don't forget that the SavingHandler must validate that dirty parent Order as well!
I should write this as a separate post and sample. I've been meaning to for years.
|