views:

128

answers:

1

Data model:

tTemplate (TemplateId int PK)
tPage (PageId int PK, TemplateId int FK)
tEmailMessage (EmailMessageId int PK, TemplateId int FK)

Requirements:

Deleting a template should be permitted only if there are no dependencies on it.

The TemplateService is responsible for deleting templates:

new TemplateService().Delete(myTemplate);

The Page and Email modules depend on the Template module, which in turn is happily unaware of these dependencies. In some setups the Page or Email module will not event be present. How would I resolve the dependency on the underlying data model? How do I get the TemplateService to start an inquiry to find out if it is ok to delete the item?

I’ve done some research on EventBrokers and Message Queues but fail to see how they alone can help me. I also fail to see how using the .net event model alone would solve this.

I'm not really looking for a way of upholding data integrity but a way of allowing for inter-service communication without causing unwanted service dependencies. I might have an implementation of the PageService where deleting the template would be ok, and where the dependancy would be resolved by setting the tPage.TemplateId to null. In other implementations I might want to create a cascading delete.

+1  A: 

This is the reason that your backing store should implement the referential integrity. Where possible, your model would implement the same thing, but deletes will only work if there is nothing referenced.

Additionally, I would recommend against checking all the data before attempting a delete as you can end up with a race condition which could cause you problems. From an efficiency point of view, you could simply implement the cascaded delete from the outset, assuming that there will always be child rows for your top level object.

The .Net model only guarantees referential integrity if you have all the data, otherwise deletes would only be attempted, not guaranteed.

Spence
I'm not really looking for a way of upholding data integrity but a way of allowing for inter-service communication without causing unwanted service dependencies. I've edited my original posting.
Marcus