As far as I've been studying the Repository pattern, the "repositories" should be responsible for data persisting and basic querying tasks, and only for that. So in a typical repository I see something like this:
public interface IProductRepository {
Product GetByID(int id);
void Add(Product item);
void Update(Product item);
void Delete(Product item);
}
But I wonder what if one uses an ORM tool like DevExpress' XPO, a repository implementation would mostly consist of one-liner methods. Does it make sense to still create this abstraction level beside XPO?
One could point out the mocking and unit testing capabilities, but for example XPO provides a powerful in-memory persistence feature, which is perfect for unit testing in 99% of times.
I think I could mention EF or NHibernate as well, those have similar features.
An additional question: if - let's say - I don't implement the repository pattern in this manner, where shall I put more complex queriyng (for example based on complex criteria or user roles), or more complex item saving logic (with logging, validation, etc.)?
Thanks for any help.
UPDATE
What about defining a generic repository interface which type-independently addresses CRUD operetaions like this:
public interface IRepository : IDisposable {
T GetByID<T>(int id);
IQueryable<T> Query<T>();
T Create<T>();
void Update<T>(T item);
void Delete<T>(T item);
}
Then I can implement it easily with with XPO, EF, or whatever ORM I choose, even with JSON text files. Is it a good middle-way solution, or does it smell? The only drawback I can see is where would I put those more complex operations mentioned above, but probably I could inherit special interfaces from this when needed.
