Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share|improve this question

2 Answers 2

up vote 5 down vote accepted

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]


--------------------------------
share|improve this answer

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

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.