Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Dependency injection in unit of work pattern using repositories

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.

  1. Use constructor injection.
  2. Use setter injection.

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.

like image 453
rashleighp Avatar asked Apr 17 '13 16:04

rashleighp


People also ask

What is repository pattern and unit of work?

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.

How does repository pattern work?

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 ...

What is repository in repository pattern?

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.


2 Answers

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

  • your UnitOfWork doesn't need to change for each new Repository
  • you are not using a service locator (considered by many to be an anti-pattern)

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.

like image 117
qujck Avatar answered Oct 01 '22 10:10

qujck


Instead of injecting repository instances inject single factory object which will be responsible for creating those instances. Your getters will then use that factory.

like image 27
Ladislav Mrnka Avatar answered Oct 01 '22 09:10

Ladislav Mrnka