CODEWITHSUNDEEP
.netnhibernatedesign-patternsrepository
Andrew Kalashnikov
Andrew Kalashnikov

Reputation: 3173

Repository pattern without interfaces

what's bad to implement repository pattern without interfaces?

Repository - class

public class WebRepository<T>
{
    private readonly Type persitentType = typeof(T);
    public virtual T GetById(int id)
    {
        return NHibernateSession.Get<T>(id);
    }
    public virtual List<T> GetAll()
    {
        return GetByCriteria();
    }
    public List<T> GetByCriteria(params ICriterion[] criterion)
    {
        ICriteria criteria = NHibernateSession.CreateCriteria(persitentType);
        foreach (ICriterion criterium in criterion)
            criteria.Add(criterium);
        return criteria.List<T>() as List<T>;
    }
    public T Save(T entity)
    {
        NHibernateSession.Save(entity);
        return entity;
    }
    public T SaveOrUpdate(T entity)
    {
        NHibernateSession.Update(entity);
        return entity;
    }
    public void Delete(T entity)
    {
        NHibernateSession.Delete(entity);
    }
    private ISession NHibernateSession
    {
        get
        {
            return SessionManager.CurrentSession;
        }
    }
}

if we would like extend repository we use ProductRepository : Repository and overrider\extend methods.

I know interfaces let us:

But if I don't want replace my nhibernate and haven't enough time to write tests. So what's the other advantages to use classic repository pattern (with IRepository<T>, IProductRepository)

Thanks, Andrew

Upvotes: 0

Views: 536

Answers (2)

šljaker
šljaker

Reputation: 7374

Mocking!
Your database may be inaccessible for some reason, and by using interface you can very easily switch between real data and dummy data.

Upvotes: 0

James
James

Reputation: 82136

There is nothing bad about implementing the repository pattern without interfaces, it's up to you whether you feel you need to use interfaces or not.

Like you have stated good reasons to use interfaces is to keep your persistance layer abstract from your business logic layer and of course for easier testability. However, if you can guarentee you won't change your backend (or at least you can't forsee it changing in the near future) and you don't intend to write tests (big mistake) then there is probably no need for you to use interfaces.

The red flag I see though is "haven't enough time to write tests". This may be the case now, however, what about in the future when you do have the time? Again, this is your decision, however, if I were you I would use interfaces (even if you didn't write tests at all) as it won't do your code any harm, nor take up that much time to do so and save you a lot of hassle in the future if you ever did decide to switch your backend or write tests.

Upvotes: 7

Related Questions