I want to create a unit of work class that wraps around repositories in a similar way to this.
The problem I'm having is trying to implement dependency injection by replacing the generic repositories in the example with an IRepository interface. In the uow in the linked article they use getters to check if the repository is instantiated and if it isn't then instantiate it.
public GenericRepository<Department> DepartmentRepository { get { if (this.departmentRepository == null) { this.departmentRepository = new GenericRepository<Department>(context); } return departmentRepository; } }
Which is strongly coupled.
I can see two ways around this.
The problem with 1 is that if I inject all the repositories I have to instantiate each repository even if I don't use them in that particular unit of work instance. Thus incurring the overhead of doing so. I was imagining using one, database-wide, unit of work class so this would lead to a lot of needless instantiating and a gigantic constructor.
The problem with 2 is that it would be easy to forget to set and end up with null reference exceptions.
Is there any sort of best practices in this scenario? And are there any other options I have missed?
I'm just getting in to dependency injection and have done all the research I can find on the topic but I may be missing something key.
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.
The idea behind the Repository pattern is to decouple the data access layer from the business access layer of the application so that the operations (such as adding, updating, deleting, and selecting items from the collection) is done through straightforward methods without dealing with database concerns such as ...
The Repository pattern. Repositories are classes or components that encapsulate the logic required to access data sources. They centralize common data access functionality, providing better maintainability and decoupling the infrastructure or technology used to access databases from the domain model layer.
A way to approach this is to not make the UnitOfWork
responsible for creating each Repository
through Container injection, but instead to make it the responsibility of each Repository
to ensure that the UnitOfWork
knows of its existence upon instantiation.
This will ensure that
UnitOfWork
doesn't need to change for each new Repository
This is best demonstrated with some code - I use SimpleInjector so the examples are based around this:
Starting with the Repository
abstraction:
public interface IRepository { void Submit(); } public interface IRepository<T> :IRepository where T : class { } public abstract class GenericRepository<T> : IRepository<T> where T : class { }
and the UnitOfWork
public interface IUnitOfWork { void Register(IRepository repository); void Commit(); }
Each Repository
must register itself with the UnitOfWork
and this can be done by changing the abstract parent class GenericRepository
to ensure it is done:
public abstract class GenericRepository<T> : IRepository<T> where T : class { public GenericRepository(IUnitOfWork unitOfWork) { unitOfWork.Register(this); } }
Each real Repository
inherits from the GenericRepository
:
public class Department { } public class Student { } public class DepartmentRepository : GenericRepository<Department> { public DepartmentRepository(IUnitOfWork unitOfWork): base(unitOfWork) { } } public class StudentRepository : GenericRepository<Student> { public StudentRepository(IUnitOfWork unitOfWork) : base(unitOfWork) { } }
Add in the physical implementation of UnitOfWork
and you're all set:
public class UnitOfWork : IUnitOfWork { private readonly Dictionary<string, IRepository> _repositories; public UnitOfWork() { _repositories = new Dictionary<string, IRepository>(); } public void Register(IRepository repository) { _repositories.Add(repository.GetType().Name, repository); } public void Commit() { _repositories.ToList().ForEach(x => x.Value.Submit()); } }
The container registration can be set up to automatically pick up all the defined instances of IRepository
and register them with a lifetime scope to ensure they all survive for the lifetime of your transaction:
public static class BootStrapper { public static void Configure(Container container) { var lifetimeScope = new LifetimeScopeLifestyle(); container.Register<IUnitOfWork, UnitOfWork>(lifetimeScope); container.RegisterManyForOpenGeneric( typeof(IRepository<>), lifetimeScope, typeof(IRepository<>).Assembly); } }
With these abstractions and an architecture built around DI you have a UnitOfWork
that knows of all Repository
's that have been instantiated within any service call and you have compile time validation that all of your repositories have been defined. Your code is open for extension but closed for modification.
To test all this - add these classes
public class SomeActivity { public SomeActivity(IRepository<Department> departments) { } } public class MainActivity { private readonly IUnitOfWork _unitOfWork; public MainActivity(IUnitOfWork unitOfWork, SomeActivity activity) { _unitOfWork = unitOfWork; } public void test() { _unitOfWork.Commit(); } }
Add these lines to BootStrapper.Configure()
//register the test classes container.Register<SomeActivity>(); container.Register<MainActivity>();
Put a break-point against the line of code:
_repositories.ToList().ForEach(x => x.Value.Submit());
And finally, run this Console test code:
class Program { static void Main(string[] args) { Container container = new Container(); BootStrapper.Configure(container); container.Verify(); using (container.BeginLifetimeScope()) { MainActivity entryPoint = container.GetInstance<MainActivity>(); entryPoint.test(); } } }
You'll find the code stops at the break point and you have one active instance of a IRepository
ready and waiting to Submit()
any changes to the database.
You can decorate your UnitOfWork to handle transactions etc. I will defer to the mighty .NetJunkie at this point and recommend you read these two articles here and here.
Instead of injecting repository instances inject single factory object which will be responsible for creating those instances. Your getters will then use that factory.
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