Best practices of implementing unit of work and repository pattern using ServiceStack.ORMLite

Question

Supposing that there are two repository interface :

interface IFooRepository
{
    void Delete(int id);
}

interface IBarRepository
{
    void Delete(int id);
}

And an IUnitOfWork interface like :

interface IUnitOfWork : IDisposable
{
    void Commit();
    void Rollback();
}

what is the best practices of implementing those interface using ServiceStack.ORMLite so that user can use them like

MyFooRepository.Delete(4);
// if an Exception throws here, Bar won't be deleted
MyBarRepository.Delete(7);

Or

using (var uow = CreateUnitOfWork())
{
    MyFooRepository.Delete(4);
    MyBarRepository.Delete(7);
    uow.Commit();  //now they are in an transaction
}

Saintpierre

I would recommend avoiding the usage of the UOW as much as possible. Passing around an open transaction like that is generally a very bad design. (In earlier revisions I was guilty of this stuff myself) – Viburnum

Answer 1

Not sure of your need for Repository + UnitOfWork patterns but I think there are some alternative solutions in ServiceStack + OrmLite that keep your code 'DRY' before you need to introduce any patterns (especially if you're mainly seeking Transaction/Rollback support). Something like below is where I would start.

public class Foo //POCO for data access
{
    //Add Attributes for Ormlite
    public int Id { get; set;  }
}

public class Bar //POCO for data access
{
    //Add Attributes for Ormlite
    public int Id { get; set; }
}

//your request class which is passed to your service
public class DeleteById 
{
    public int Id { get; set; }
}

public class FooBarService : MyServiceBase //MyServiceBase has resusable method for handling transactions. 
{
    public object Post(DeleteById request)
    {
        DbExec(dbConn =>
                   {
                       dbConn.DeleteById<Foo>(request.Id);
                       dbConn.DeleteById<Bar>(request.Id);
                   });

        return null;
    }
}

public class MyServiceBase : Service
{
    public IDbConnectionFactory DbFactory { get; set; }

    protected void DbExec(Action<IDbConnection> actions)
    {
        using (var dbConn = DbFactory.OpenDbConnection())
        {
            using (var trans = dbConn.OpenTransaction())
            {
                try
                {
                    actions(dbConn);
                    trans.Commit();
                }
                catch (Exception ex)
                {
                    trans.Rollback();
                    throw ex;
                }
            }
        }
    }
} 

Some references...

https://github.com/ServiceStack/ServiceStack.RedisWebServices - The above code is modified from this example

https://groups.google.com/forum/#!msg/servicestack/1pA41E33QII/R-trWwzYgjEJ - discussion about layers in ServiceStack

http://ayende.com/blog/3955/repository-is-the-new-singleton - Ayende Rahien (NHibernate core contributor) on Repository pattern

Erichericha

In case you need special / complex logic sql where would you put them ? – Monophysite

I guess you can do as much special/complex logic sql as you want within the action/function sent to the DbExec method. Could also write a stand-alone function and pass it (the action/function) within the block. Also, this example is probably not the best approach for complex situations. – Erichericha