I overrode the Delete() method in my EntityBase class and turned in into a template method.  The sub-class can provide a VerifierCollection by overriding and implementing a method called DeleteVerifiers() and then the template method tells the verifier engine to execute these verifiers.  Upon success, I calls a method called DeleteCore() that performs the actual delete after successful verification.  I am throwing an exception from the Delete() method for now since this is the quickest things that works.  I had considered providing a delete service and I’ll probably go this direction eventually.

Thanks for the input.

It’s a good question.

The customer is correct that, once an object has been deleted, one cannot traverse its graph … I don’t think you should be able to do so.

What to do? How to check if delete is ok before deleting?

The obvious first answer is to override the Delete method and test the object before deleting.

But perhaps you want to do that in a generalized way, even taking advantage of the VerificationEngine’s ability to acquire and deliver rules. The VE wasn’t designed to verify delete (or add or any object operation other than save) but it would seem easy to extend for such purposes. We can add any kind of VerificationRule to the VE’s inventory and retrieve it by type and name (although I don’t remember precisely how to do so as I write this).

It would be essential to clear all triggers for such a rule – we don’t want it to fire on property change or save … or at least I don’t think so.

I suppose what I’d do next is override a business object base class Delete method such that it looked for delete verification rules in the VE and, if found, ran them. 

Of course if the rule fails, you have to have some way of communicating that fact back to the UI. I don’t know that throwing an exception is a good idea. Some eventing mechanism might seem appropriate but I wouldn’t want to hook up an event to every object and I’d be wary of anything that might prevent a transient entity from being garbage collected when it went out of scope. I strongly advise against attaching and detaching event handlers to individual entities.

This leads me instead to the notion of some kind of service that the Delete method can find and invoke for communicating a delete verification failure; the UI could subscribe to that service. Use the ServiceLocator pattern. You know the drill.

Clearly it would be a good idea for IdeaBlade to develop a recommendation for verifying basic operations on entities (add, delete). I figured we’d get into that when we developed our SecurityEngine – the object level security parallel to the VerificationEngine.

Because we have not done this yet, it remains for the customer to consider these ideas here and spike on them. I’d sure like to know what he thinks.

In the interested of consolidating my business rules, I’d prefer to use verification to enforce my deletion criteria rather than overriding the delete method.  The trouble is that when an entity is marked “deleted” then you cannot traverse to its related objects because a deleted entity has all NullEntity values for its relations.  Can you suggest a recommended practice for verifying that an entity can be deleted when I need to check values in related entities in order to make this determination?