I'm struggling to understand the relationship between the Repository and Unit of Work patterns despite this kind of question being asked so many times. Essentially I still don't understand which part would save/commit data changes - the repository or the unit of work?
Since every example I've seen relates to using these in conjunction with a database/OR mapper let's make a more interesting example - lets persist the data to the file system in data files; according to the patterns I should be able to do this because where the data goes is irrelevant.
So for a basic entity:
public class Account { public int Id { get; set; } public string Name { get; set; } }
I imagine the following interfaces would be used:
public interface IAccountRepository { Account Get(int id); void Add(Account account); void Update(Account account); void Remove(Account account); } public interface IUnitOfWork { void Save(); }
And I think in terms of usage it would look like this:
IUnitOfWork unitOfWork = // Create concrete implementation here IAccountRepository repository = // Create concrete implementation here // Add a new account Account account = new Account() { Name = "Test" }; repository.Add(account); // Commit changes unitOfWork.Save();
Bearing in mind that all data will be persisted to files, where does the logic go to actually add/update/remove this data?
Add()
, Update()
and Remove()
methods? It sounds logical to me to have all the code which reads/writes files in one place, but then what is the point of the IUnitOfWork
interface?IUnitOfWork
implementation, which for this scenario would also be responsible for data change tracking too? To me this would suggest that the repository can read files while the unit of work has to write files but that the logic is now split into two places.The repository and unit of work patterns are intended to create an abstraction layer between the data access layer and the business logic layer of an application.
You should have a repository factory that can create the repository with either an existing unit of work passed as an argument or a new unit of work (since both are valid use cases).
The Repository pattern makes it easier to test your application logic. The Repository pattern allows you to easily test your application with unit tests. Remember that unit tests only test your code, not infrastructure, so the repository abstractions make it easier to achieve that goal.
By definition, the Repository Design Pattern in C# mediates between the domain and the data mapping layers using a collection-like interface for accessing the domain objects. Repository Design Pattern separates the data access logic and maps it to the entities in the business logic.
Repository can work without Unit Of Work, so it can also have Save method.
public interface IRepository<T> { T Get(int id); void Add(T entity); void Update(T entity); void Remove(T entity); void Save(); }
Unit Of Work is used when you have multiple repositories (may have different data context). It keeps track of all changes in a transaction until you call Commit method to persist all changes to database(file in this case).
So, when you call Add/Update/Remove in the Repository, it only changes the status of the entity, mark it as Added, Removed or Dirty... When you call Commit, Unit Of Work will loop through repositories and perform actual persistence:
If repositories share the same data context, the Unit Of Work can work directly with the data context for higher performance(open and write file in this case).
If repositories have different data context(different databases or files), the Unit Of Work will call each repository's Save method in a same TransactionScope.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With