views:

59

answers:

1

My app uses a business layer which calls a repository which uses linq to sql.

I have an Item class that has an enum type property and an ItemDetail property.

I need to implement a delete method that:

(1) always delete the Item (2) if the item.type is XYZ and the ItemDetail is not null, delete the ItemDetail as well.

My question is where should this logic be housed?

If I have it in my business logic which I would prefer, this involves two separate repository calls, each of which uses a separate datacontext. I would have to wrap both calls is a System.Transaction which (in sql 2005) get promoted to a distributed transaction which is not ideal.

I can move it all to a single repository call and the transaction will be handled implicitly by the datacontext but feel that this is really business logic so does not belong in the repository.

Thoughts?

Carrie

A: 

I'm not sure I really understood your question, but if it's a single repository - could you have your repository expose two different methods handling the two types of deletion? Then the logic for determining which repository method to call would stay in the businesslayer where it seems to fit best?

Or maybe you can find some help in this post: http://stackoverflow.com/questions/2045461/where-should-the-transaction-boundary-be-in-a-repository-pattern

Mitch99