views:

200

answers:

1

I'm in the process of catching up on technical documentation for a project I completed some months ago, and one I'm coming close to finishing. I used repositories to abstract out the data access layer in both and was writing a short summary of the pattern on our wiki at work.

It was whilst writing this summary that I realised I took a slightly different approach the second time.

One used an explicit InsertOnSubmit method coupled with a Unit of Work and an implicit update with the UoW tracking changes. The other had a Save method which inserted new entries and updated existing (without a UoW).

Which approach would you typically favour? Consider the usual CRUD scenarios, where should the the responbility for each of them lie?

+2  A: 

I think whether a repository uses Unit of Work, caching, or any other related concepts should be left to the implementation. I prefer for the interface to resemble a data store which is aligned with the domain model at hand. So that a customer repository would look something like this:

interface ICustomerRepository
{
    Customer Load(int id);
    IEnumerable<Customer> Search(CustomerQuery q);
    void Save(Customer c);
    void Delete(Customer c);
}

This can be easily implemented by something like NHibernate, or NHibernate with NHibernate.Linq, or a direct SQL library, or even an XML or flat-file store. If possible, I like the keep the concept of transaction outside of the repository, or at a more global scope so that operations of several repositories may be part of a single transaction.

eulerfx