Question

I’m developing a web service using NHibernate, WCF and Oracle 11g R1. The web service is pretty simple: it maps DTOs to POCOs and performs various CRUD operations on them based on the operation called. Each entity has its own set of CRUD methods – this is a temporary, but necessary for the time being.

I’m looking for input on a good Repository pattern that will support this 1:1 CRUD service layer now and not be entirely thrown away when the API needs to become more robust. Right now consumers will update entities using this service “piece-by-piece”, but later, these operations will be more robust. I.e. A service operation will work with more than one entity.

So, as an example I have entities A, B and C. There will be CRUD service operations for A, B, and C. Currently, when the consumer works with A locally, it’s most always also working with B and C. When it uses the service to interact A, B and C, it will need to make three separate service calls. The majority of the business logic is residing on the consumer for now, but when that moves into the service layer, an service operation will be created so that it can work with A, B and C in one call.

I’ve done a fair amount of Googling on the Repository pattern and NHibernate (and WCF), thus far I’ve read:

http://daniel.wertheim.se/2009/10/21/nhibernate-hbmnhibcontext-fluentnhibcontext/
NHibernate session management in WCF application
http://davybrion.com/blog/2008/06/managing-your-nhibernate-sessions/
http://davybrion.com/blog/2009/12/using-nhibernate-in-your-service-layer/
http://jeffreypalermo.com/blog/use-this-nhibernate-wrapper-to-keep-your-repository-classes-simple/

And a bunch others. Two basic things I want to achieve:

• One ISession per request
• One ITransaction per request

I thought it would make sense to have a Repository per entity now and then eventually some type of aggregate root Repository could be added on top of those when then service operations were made more complex. Would that even be necessary?

Thanks.

Answer 1

This MSDN article by K Scott Allen combines repositories with the UnitOfWork pattern.

In the case of NHibernate your UnitOfWork would be created with an NHibernate ISession, and if required you could make each UoW transacted. Obviously the UoW would be responsible for creating the various repositories from the ISession it is provided with…

public class NHibernateUnitOfWork : IUnitOfWork

    public NHibernateUnitOfWork(ISession session)
    {
        // if transacted you would begin the transaction here also
        _session = session;
    }

    private ISession _session;

    private IRepository<A> _aRepository   
    public IRepository<A> ARepository
    {
        get
        {
            if(_aRepository == null)
                _aRepository = new NHibernateRepository<A>(_session);

            return _aRepository;    
        }
    }

    private IRepository<B> _bRepository   
    public IRepository<B> BRepository
    {
        get
        {
            if(_bRepository == null)
                _bRepository = new NHibernateRepository<B>(_session);

            return _bRepository;    
        }
    }

    private IRepository<C> _cRepository   
    public IRepository<C> CRepository
    {
        get
        {
            if(_cRepository == null)
                _cRepository = new NHibernateRepository<C>(_session);

            return _cRepository;    
        }
    }

    public void Commit()
    {
        // if transacted you would commit the transaction here
        _session.Flush();
    }

    public void Dispose()
    {
        _session.Dispose();
    }
}