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
Best Answer
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:
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
orservice 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.