Relationship between Repository and Unit of Work

Question

I am going to implement a repository, and I would like to use the UOW pattern since the consumer of the repository could do several operations, and I want to commit them at once.

After read several articles about the matter, I still don't get how to relate this two elements, depending on the article it is being done in a way u other.

Sometimes the UOW is something internal to the repository:

public class Repository
{
    UnitOfWork _uow;

    public Repository()
    {
       _uow = IoC.Get<UnitOfWork>();
    }

    public void Save(Entity e)
    {
        _uow.Track(e);
    }

    public void SubmittChanges()
    {
        SaveInStorage(_uow.GetChanges());
    }
}

And sometimes it is external:

public class Repository
{
    public void Save(Entity e, UnitOfWork uow)
    {
        uow.Track(e);
    }

    public void SubmittChanges(UnitOfWork uow)
    {
        SaveInStorage(uow.GetChanges());
    }
}

Other times, is the UOW whom references the Repository

public class UnitOfWork
{
    Repository _repository;

    public UnitOfWork(Repository repository)
    {
       _repository = repository;
    }

    public void Save(Entity e)
    {
        this.Track(e);
    }

    public void SubmittChanges()
    {
       _repository.Save(this.GetChanges());
    }
}

How are these two elements related? UOW tracks the elements that needs be changed, and repository contains the logic to persist those changes, but... who call who? Does the last make more sense?

Also, who manages the connection? If several operations have to be done in the repository, I think using the same connection and even transaction is more sound, so maybe put the connection object inside the UOW and this one inside the repository makes sense as well.

Cheers

Answer 1

Re: "UOW tracks the elements that needs be changed, and repository contains the logic to persist those changes, but... who call who?"

You understand the basic responsibilities of these classes. You say that each of the articles, that you've read, connects them together in different ways. This implies that the decision about "who calls who" is up to you.

I'd try to sketch out the problem in terms of 'layers' whilst being guided by basic principals of good software design such as Cohesion, Decoupling, Reusability, Unit-Testability etc.

To quote Eric Evans Domain Driven Design, (2004) Addison Wesley, pg 69:

The essential principal [of Layered Archituctures] is that any element of a layer depends only on other elements in the same layer or on elements of the layers "beneath" it.

In my opinion, both the UOW and Repo are two very different classes that have clear, independent, responsibilities. To start with, I wouldn't make either invoke the other.

I think you need some third client class (i.e. either a controller or service class) that really knows 'when and what to get' from the repo and 'when' to save the transaction. This client sits relatively high in the architecture (so can know about more classes) and can do some orchestration between the two.

--------------------------------

         [Client]
           /   \
----------/---- \---------------
         /       \
        V         V
[Unit Of Work]  [Repo]


--------------------------------

Answer 2

The methods are most commonly given to the UOW interface (which is normally constructed via a factory).

You typically call methods on a UOW interface from command pattern class(es) / facade. Since UOW simply defers database IO until later (to prevent you from having long-running transactions or multiple calls to the database that may be unnecessary), working with the UOW should be at the same level that you would normally work with your database.

Microsoft has a very thorough post on the UOW pattern:

http://msdn.microsoft.com/en-us/magazine/dd882510.aspx