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.
ReplyDeleteMaybe you should mention that you pulled that code from the ADO team blog.
ReplyDeleteI 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?
ReplyDeleteIf LINQ is really important for you is only because your Repository should be a ICollection<T> and avoid all FindByXYZ.
ReplyDeleteIf 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.
ReplyDeleteI 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.
ReplyDeleteI must admit, I've never fully understood a "repository" like the above. It's just a DAO isn't it?
ReplyDeleteRepositories I've created are wrappers to the persistence technology rather than an object. e.g.
public interface IDataRepository
{
Add(object entity);
IQueryable<T> Query<T>
Persist();
..etc
}
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.
ReplyDeleteFindBy 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).
ReplyDeleteI 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