If you want LINQ2NH or you are planning to use LINQ2EF please don’t say me that you are defining Repository like this
public interface ICustomerRepository
Customer GetCustomerById(string id);
IEnumerable<Customer> FindByName(string name);
void AddCustomer(Customer customer);
This comment has been removed by the author.ReplyDelete
Maybe you should mention that you pulled that code from the ADO team blog.ReplyDelete
I like there work and posts, but like you say. with linq, that example is kinda ridiculous.
Can you please explain this further? Do you mean it's ridiculous to have separate methods to do the Linq queries when the client code can do it instead?ReplyDelete
If LINQ is really important for you is only because your Repository should be a ICollection<T> and avoid all FindByXYZ.ReplyDelete
If you use a Repository as above you don't need a LINQ provider.
- but then the entire repository would be kind of pointless, Fabio - a session provider would be enough.ReplyDelete
I usually use HQL in my repositories because it reads well - but I will probably prefer LINQ when it matures, simply because it is known by the compiler and thus will be more friendly to refactoring... but the LINQ2NH will still only be put in my repositories.
A repository should mimic a collection. So methods like FindByUserName and AddCustomer break the pattern. In addition, they're unnecessary if you're using Linq.ReplyDelete
I must admit, I've never fully understood a "repository" like the above. It's just a DAO isn't it?ReplyDelete
Repositories I've created are wrappers to the persistence technology rather than an object. e.g.
public interface IDataRepository
I guess I might have a specific query method (e.g. Findbyname(string name) if I need to do something that the existing LINQ-NH can't do or HQL is better at. At least this way if I want to rip out NH in a few years time it's easier to do so and I don't have lots of mini-repositories to deal with.
Can someone explain the benefits of the "DAO" like repository?
I really don't know.. I've been trough this many times and still I see benefits of both approaches.ReplyDelete
FindBy methods hide the implementation. I might want to implement them as SQLQuery, HQLQuery or anything else if I need to. They define the contract and don't force the implementation.
... but they require some extra code and the interface of the repository gets bloated...
For some reason I'm using DAO. When we will have LINQ fully supported I will begin using IRepository<T> (may be).ReplyDelete
I mainly use DAO pattern for all persistance related tasks (encapsulating NH related code). Adding a querable, collection pulling finder method is quite tempting and seems harmless to me.ReplyDelete