I am working on a small ASP.NET MVC project at the moment.
I am trying to implement Nhibernate to persist on a MS Sql Server database.
Having spent long hours studying DDD and other projects found on the Internet I have decided to go for the repository pattern.
Now I ma facing a dilemma.
Do I really need a repository when using Nhinbernate?
Wouldn’t it be better to have a Service Layer (I don’t have a Service Layer at the moment) which interacts with Nhinbernate avoiding to write many times something like that:
public Domain.Reminder GetById(Guid Code)
{
return (_session.Get<Domain.Reminder>(Code));
}
public Domain.Reminder LoadById(Guid Code)
{
return (_session.Load<Domain.Reminder>(Code));
}
public bool Save(Domain.Reminder Reminder)
{
_session.SaveOrUpdate(Reminder);
return (true);
}
public bool Delete(Domain.Reminder Reminder)
{
_session.Delete(Reminder);
return (true);
}
I found an old Ayende’s POST which is against repositories.
I know there’s a huge debate around these topics and the answer is always … depends, but it seems to me that with too many layers of abstractions things get more complicated and hard to follow.
Am I wrong?
Ayende was against writing a repository the way you did because of the reasons you asked this question, it is repetitive code and NH can handle all of it anyways. He advocates just calling NH directly as you would a repository, and stop worrying about it.
I pretty much agree with him. There really isn’t much to gain except for more work.