What is your understanding of the Repository Pattern?
-
05-07-2019 - |
Question
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?
Solution
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.