I'm using UnitOfWork and Repository patterns in my project. I'm trying to code clean.
This is my IUnitOfWork.cs (Application Layer)
public interface IUnitOfWork : IDisposable
{
int Save();
IGenericRepository<TEntity> Repository<TEntity>() where TEntity : class;
}
The implementation UnitOfWork.cs : (Persistence Layer)
public class UnitOfWork : IUnitOfWork
{
private readonly DBContext _context;
private Hashtable _repositories;
public UnitOfWork(DBContext context)
{
_context = context;
}
public IGenericRepository<T> Repository<T>() where T : class
{
if (_repositories == null)
_repositories = new Hashtable();
var type = typeof(T).Name;
if (!_repositories.ContainsKey(type))
{
var repositoryType = typeof(GenericRepository<>);
var repositoryInstance =
Activator.CreateInstance(repositoryType
.MakeGenericType(typeof(T)), _context);
_repositories.Add(type, repositoryInstance);
}
return (IGenericRepository<T>)_repositories[type];
}
public int Save()
{
// Save changes with the default options
return _context.SaveChanges();
}
// etc.. Dispose()
}
My IGenericRepository.cs : (Application Layer)
public interface IGenericRepository<TEntity>
where TEntity : class
{
void Update(TEntity entity);
void Delete(object id);
void InsertList(IEnumerable<TEntity> entities);
// etc..
}
In my service : (Application Layer)
var result = UnitOfWork.Repository<Entities.Example>().Delete(id);
And using Unity, I inject the dependency in the container.
container.RegisterType<IUnitOfWork, UnitOfWork>(new HierarchicalLifetimeManager())
And it works like a charm.
Now I have a custom Repository ICustomRepository:
public interface ICustomRepository: IGenericRepository<Entities.Custom>
{
void Test();
}
How can I access the Test() function using my IUnitOfWork?
var result = UnitOfWork.Repository<Entities.Custom>().Test(); // not working
UPDATE:
#Thomas Cook give me a way using cast :
(UnitOfWork.Repository<Entities.Custom>() as ICustomRepository).Test();
I get a NullReferenceException:
System.NullReferenceException: 'Object reference not set to an instance of an object.'
You'll have to cast, because UnitOfWork Repository method returns a IGenericRepository which doesn't declare Test. So you'll need to cast the returned value to a ICustomRepository which inherits IGenericRepository and bolts on the Test method.
Whilst casting would work (if the repository wouldn't be null) you could ask yourself is this is useful; What good is an abstraction of you're going to depend on knowing its details, i.e.: the caller now knows it actually is a non-generic interface and type, namely a ICustomRepository (btw the reason you get the null ref probably is because UnitOfWork only creates the generic repositories and your custom repo doesn't exist).
A better (IMO) and more explicit way to design your Unit of Work not in a generic way but list all repositories:
public interface IUnitOfWork : IDisposable
{
int Save();
ICustomRepository CustomRepository {get;}
IGenericRepository<Entities.Example> ExampleRepository {get;}
// etc...
}
This way you don't need any casting or know its details.
Furthermore, I would recommend to pass all repositories to the constructor of the UnitOfWork from your dependency injection and don't make its responsibility too big.
public UnitOfWork(DBContext context, ICustomRepository customRepository ...)
{
//
}
Just make sure you use the same instance of DbContext in your Unit of Work as the one that's injected into your repositories.
Related
I am making a generic repository but for some entities I also need functionalities not provided by the generic repository. I have an interface IGenericRepository and concrete implementation as GenericRepository with basic CRUD operations. Further I have a studentRepository that uses the generic repository but also has functionalities of its own independent from the Generic Repository for which i have an Interface called IStudentRepository.
Here is the sample code:
public interface IGenericEntityRepository<T>
{
Delete(T entity);
T Get(int id);
IEnumerable<T> GetAll();
Add(T entity);
Update(T entity);
}
public class GenericEntityRepository<T> : IGenericEntityRepository<T> where T : class
{
protected readonly ApplicationDbContext _applicationDbContext;
public GenericEntityRepository(ApplicationDbContext applicationDbContext)
{
this._applicationDbContext = applicationDbContext;
}
//Generic Repository Implementations....
}
public interface IStudentRepository
{
string GetFullName(Student student)
double GetGpa(Student student)
}
public class StudentRepository: GenericRepository<Student>, IStudentRepository
{
public StudentRepository(ApplicationDbContext applicationDbContext) : base(applicationDbContext)
{}
//IStudentRepository functions' implementations...
}
Now I need to inject this StudentRepository to my StudentsController
public class StudentsController : Controller
{
private readonly IGenericEntityRepository<Student> _genericStudentRepository;
public StudentsController(IGenericEntityRepository<Student> _genericStudentRepository)
{
this._genericStudentRepository = genericRepository;
}
public void testAccessibility()
{
this._genericStudentRepository.GetAll() //valid call
this._genericStudentRepository.GetAllGpa() //invalid Call
***As expected cause IGenericEntityRepository doesn't have that ***function
}
}
As you can see the probelem here, if I inject IGenericEntityRepository I only get the genericrepository functionalities. If i want the functionalities of Student repository not included in genericRepository I have to inject both IGenericEntityRepository and IStudentRepository like below and vice versa.
public class StudentsController : Controller
{
private readonly IGenericEntityRepository<Student> _genericStudentRepository;
private readonly IStudentRepository _studentsRepository;
public StudentsController(IGenericEntityRepository<Student> _genericStudentRepository, IStudentRepository studentsRepository)
{
this._genericStudentRepository = genericRepository;
this.__studentsRepository = studentsRepository;
}
public void testAccessibility()
{
this._genericStudentRepository.GetAll() //valid call
this._studentsRepository.GetAllGpa() //valid call
}
}
Is there a better way to do this? Doesn't feel right injecting two contextually same but coding wise different objects like this.
You can have IStudentRepository extend IGenericEntityRepository<T>:
public interface IStudentRepository : IGenericEntityRepository<Student>
{
string GetFullName(Student student)
double GetGpa(Student student)
}
Now injecting IStudentRepository should be enough to use all the functions.
I'm developing an ASP.NET MVC 4 Web Api, with C#, .NET Framework 4.0, Entity Framework Code First 6.0 and Ninject.
I have two different DbContext custom implementations to connect with two different databases.
This is my NinjectConfigurator class (partial):
private void AddBindings(IKernel container)
{
container.Bind<IUnitOfWork>().
To<TRZICDbContext>().InRequestScope().Named("TRZIC");
container.Bind<IUnitOfWork>().
To<INICDbContext>().InRequestScope().Named("INIC");
container.Bind<IGenericRepository<CONFIGURATIONS>>().
To<GenericRepository<CONFIGURATIONS>>();
container.Bind<IGenericRepository<INCREMENTAL_TABLE>>().
To<GenericRepository<INCREMENTAL_TABLE>>();
// More implementation...
}
CONFIGURATIONS is a TRZIC table and INCREMENTAL_TABLE is an INIC table.
I'm using a IGenericRepository and here it's where I have the problems:
public class GenericRepository<TEntity> : IGenericRepository<TEntity> where TEntity : class
{
protected DbSet<TEntity> DbSet;
private readonly DbContext dbContext;
public GenericRepository(IUnitOfWork unitOfWork)
{
dbContext = (DbContext)unitOfWork;
DbSet = dbContext.Set<TEntity>();
}
// Hidden implementation..
}
I don't know how to use the [Named("TRZIC")] here public GenericRepository(IUnitOfWork unitOfWork) or maybe I need to use it elsewhere.
Here the IUnitOfWork implementation depends on TEntity.
Any advice?
Let's start with the basics.
As far as i know named bindings work only with constant values attributed in code, like the [Named("foo")] attribute, or otherwise by using "service location" like IResolutionRoot.Get<T>(string name). Either does not work for your scenario, so a named binding is out of the question.
That leaves you with conditional bindings (.When(...) methods).
You've got 2 database with n entities each.
2 Database means two configurations means 2 different IUnitOfWork configuration.
However, the "user" is not requesting a specific database, but a specific entity.
Thus you'll need a map entity-->database (a dictionary). I don't think there's a way to get around that, but you may devise some kind of convention & implement it by convention, so you don't have to type and maintain a lot of code.
Solution 1: .WhenInjectedInto<>
with out of the box ninject features, and lots of manual labor:
Bind<IUnitOfWork>().To<UnitOfWorkOfDatabaseA>()
.WhenInjectedInto<IRepository<SomeEntityOfDatabaseA>>();
Bind<IUnitOfWork>().To<UnitOfWorkOfDatabaseA>()
.WhenInjectedInto<IRepository<SomeOtherEntityOfDatabaseA>>();
Bind<IUnitOfWork>().To<UnitOfWorkOfDatabaseB>()
.WhenInjectedInto<IRepository<SomeEntityOfDatabaseB>>();
you get the drift,.. right?
Solution 2.1: Custom When(..) implementation
Not so much manual labor and maintenance anymore.
Let me just dump the code on you, see below:
public interface IRepository
{
IUnitOfWork UnitOfWork { get; }
}
public class Repository<TEntity> : IRepository<TEntity>
{
public IUnitOfWork UnitOfWork { get; set; }
public Repository(IUnitOfWork unitOfWork)
{
UnitOfWork = unitOfWork;
}
}
public interface IUnitOfWork { }
class UnitOfWorkA : IUnitOfWork { }
class UnitOfWorkB : IUnitOfWork { }
public class Test
{
[Fact]
public void asdf()
{
var kernel = new StandardKernel();
kernel.Bind(typeof (IRepository<>)).To(typeof (Repository<>));
kernel.Bind<IUnitOfWork>().To<UnitOfWorkA>()
.When(request => IsRepositoryFor(request, new[] { typeof(string), typeof(bool) })); // these are strange entity types, i know ;-)
kernel.Bind<IUnitOfWork>().To<UnitOfWorkB>()
.When(request => IsRepositoryFor(request, new[] { typeof(int), typeof(double) }));
// assert
kernel.Get<IRepository<string>>()
.UnitOfWork.Should().BeOfType<UnitOfWorkA>();
kernel.Get<IRepository<double>>()
.UnitOfWork.Should().BeOfType<UnitOfWorkB>();
}
private bool IsRepositoryFor(IRequest request, IEnumerable<Type> entities)
{
if (request.ParentRequest != null)
{
Type injectInto = request.ParentRequest.Service;
if (injectInto.IsGenericType && injectInto.GetGenericTypeDefinition() == typeof (IRepository<>))
{
Type entityType = injectInto.GetGenericArguments().Single();
return entities.Contains(entityType);
}
}
return false;
}
}
Solution 2.2 Custom convention based When(...)
Let's introduce a small convention. Entity names of database TRZIC start with TRZIC, for example TRZIC_Foo. Entity names of database INIC start with INIC, like INIC_Bar. We can now adapt the previous solution to:
public class Test
{
[Fact]
public void asdf()
{
var kernel = new StandardKernel();
kernel.Bind(typeof (IRepository<>)).To(typeof (Repository<>));
kernel.Bind<IUnitOfWork>().To<UnitOfWorkA>()
.When(request => IsRepositoryFor(request, "TRZIC")); // these are strange entity types, i know ;-)
kernel.Bind<IUnitOfWork>().To<UnitOfWorkB>()
.When(request => IsRepositoryFor(request, "INIC"));
// assert
kernel.Get<IRepository<TRZIC_Foo>>()
.UnitOfWork.Should().BeOfType<UnitOfWorkA>();
kernel.Get<IRepository<INIC_Bar>>()
.UnitOfWork.Should().BeOfType<UnitOfWorkB>();
}
private bool IsRepositoryFor(IRequest request, string entityNameStartsWith)
{
if (request.ParentRequest != null)
{
Type injectInto = request.ParentRequest.Service;
if (injectInto.IsGenericType && injectInto.GetGenericTypeDefinition() == typeof (IRepository<>))
{
Type entityType = injectInto.GetGenericArguments().Single();
return entityType.Name.StartsWith(entityNameStartsWith, StringComparison.OrdinalIgnoreCase);
}
}
return false;
}
}
This way we don't need explicit mapping (EntityA, EntityB, EntityC) => DatabaseA, (EntityD, EntityE, EntityF) => DatabaseB).
If you say that IUnitOfWork depends on TEntity why not make IUnitOfWork generic too?
public class TRZIC {}
public class INIC {}
public interface IUnitOfWork<TEntity> {}
public class TRZICDbContext : DbContext, IUnitOfWork<TRZIC> {}
public class INICDbContext : DbContext, IUnitOfWork<INIC> {}
public interface IGenericRepository<TEntity> {}
public class GenericRepository<TEntity> : IGenericRepository<TEntity>
where TEntity : class
{
public GenericRepository(IUnitOfWork<TEntity> unitOfWork)
{
var dbContext = (DbContext) unitOfWork;
}
}
private static void AddBindings(IKernel container)
{
container
.Bind<IUnitOfWork<TRZIC>>()
.To<TRZICDbContext>();
container
.Bind<IUnitOfWork<INIC>>()
.To<INICDbContext>();
container
.Bind<IGenericRepository<TRZIC>>()
.To<GenericRepository<TRZIC>>();
container
.Bind<IGenericRepository<INIC>>()
.To<GenericRepository<INIC>>();
}
Another solution that also leverages code readability:
public interface IUnitOfWork {}
// both named A and B
public class UnitOfWorkA : IUnitOfWork {}
public class UnitOfWorkB : IUnitOfWork {}
public abstract class GenericRepository<TEntity> : IGenericRepository<TEntity> where TEntity : class
{
protected DbSet<TEntity> DbSet;
private readonly DbContext dbContext;
public GenericRepository(IUnitOfWork unitOfWork)
{
dbContext = (DbContext)unitOfWork;
DbSet = dbContext.Set<TEntity>();
}
// other IGenericRepository methods
}
public class GenericRepositoryForA<TEntity> : GenericRepository<TEntity>
{
public GenericRepositoryForA([Named("A")]IUnitOfWork unitOfWork)
: base(unitOfWork)
{
}
}
public class GenericRepositoryForB<TEntity> : GenericRepository<TEntity>
{
public GenericRepositoryForB([Named("B")]IUnitOfWork unitOfWork)
: base(unitOfWork)
{
}
}
This allows you to ask for a specific database context as a dependency, or get both of them if required. And you only need to implement GenericRepository once.
It greatly improvises code visiblity because you actually know which database context you are using by looking at the variable type/name, instead of getting a IUnitOfWork injected without any visual detail on its actual type.
I'd suggest adding some extra interfaces if you want to unittest it (you should!).
Simply adding
public interface IGenericRepositoryForA<TEntity> : IGenericRepository<TEntity>
and just let GenericRepositoryForA<TEntity> implement it aswell.
Another solution:
private void AddBindings(IKernel container)
{
container.Bind<IUnitOfWork>().To<TRZICDbContext>().InRequestScope();
container.Bind<IGenericRepository<CONFIGURATIONS>>().
To<GenericRepository<CONFIGURATIONS>>();
container.Bind<IGenericRepository<INCREMENTAL_TABLE>>().
To<GenericRepository<INCREMENTAL_TABLE>>().WithConstructorArgument("unitOfWork", new INICDbContext());
// More code..
}
I have used WithConstructorArgument to indicate that I want to use INICDbContext.
I don't know if this is correct or not.
This is the first time I am implementing a more domain-driven design approach. I have decided to try the Onion Architecture as it focuses on the domain rather than on infrastructure/platforms/etc.
In order to abstract away from Entity Framework, I have created a generic repository with a Unit of Work implementation.
The IRepository<T> and IUnitOfWork interfaces:
public interface IRepository<T>
{
void Add(T item);
void Remove(T item);
IQueryable<T> Query();
}
public interface IUnitOfWork : IDisposable
{
void SaveChanges();
}
Entity Framework implementations of IRepository<T> and IUnitOfWork:
public class EntityFrameworkRepository<T> : IRepository<T> where T : class
{
private readonly DbSet<T> dbSet;
public EntityFrameworkRepository(IUnitOfWork unitOfWork)
{
var entityFrameworkUnitOfWork = unitOfWork as EntityFrameworkUnitOfWork;
if (entityFrameworkUnitOfWork == null)
{
throw new ArgumentOutOfRangeException("Must be of type EntityFrameworkUnitOfWork");
}
dbSet = entityFrameworkUnitOfWork.GetDbSet<T>();
}
public void Add(T item)
{
dbSet.Add(item);
}
public void Remove(T item)
{
dbSet.Remove(item);
}
public IQueryable<T> Query()
{
return dbSet;
}
}
public class EntityFrameworkUnitOfWork : IUnitOfWork
{
private readonly DbContext context;
public EntityFrameworkUnitOfWork()
{
this.context = new CustomerContext();;
}
internal DbSet<T> GetDbSet<T>()
where T : class
{
return context.Set<T>();
}
public void SaveChanges()
{
context.SaveChanges();
}
public void Dispose()
{
context.Dispose();
}
}
The Customer repository:
public interface ICustomerRepository : IRepository<Customer>
{
}
public class CustomerRepository : EntityFrameworkRepository<Customer>, ICustomerRepository
{
public CustomerRepository(IUnitOfWork unitOfWork): base(unitOfWork)
{
}
}
ASP.NET MVC controller using the repository:
public class CustomerController : Controller
{
UnityContainer container = new UnityContainer();
public ActionResult List()
{
var unitOfWork = container.Resolve<IUnitOfWork>();
var customerRepository = container.Resolve<ICustomerRepository>();
return View(customerRepository.Query());
}
[HttpPost]
public ActionResult Create(Customer customer)
{
var unitOfWork = container.Resolve<IUnitOfWork>();
var customerRepository = container.Resolve<ICustomerRepository>();;
customerRepository.Add(customer);
unitOfWork.SaveChanges();
return RedirectToAction("List");
}
}
Dependency injection with unity:
container.RegisterType<IUnitOfWork, EntityFrameworkUnitOfWork>();
container.RegisterType<ICustomerRepository, CustomerRepository>();
Solution:
PROBLEMS?
Repository implementation (EF code) is very generic. It all sits in side the EntityFrameworkRepository<T> class. Concrete model repositories do not contain any of this logic. This saves me from writing tons of redundant code, but possibly sacrifices flexibility?
The ICustomerRepository and CustomerRepository classes are basically empty. They are purely there to provide abstraction. As far as I understand, this fits with the vision of the Onion Architecture, where infrastructure and platform-dependent code sits on the outside of your system, but having empty classes and empty interfaces feels wrong?
To use a different persistence implementation (say Azure Table Storage), then a new CustomerRepository class would need to be created and would inherit a AzureTableStorageRepository<T>. But this could lead to redundant code (multiple CustomerRepositories)? How would this effect mocking?
Another implementation (say Azure Table Storage) has limitations on transnational support so the a AzureTableStorageUnitOfWork class wouldn't work in this context.
Are there any other issues with the way I have done this?
(I have taken most of my inspiration from this post)
I can say that this code is good enough for the first time try but it does have some places to improve.
Let's go through some of them.
1. Dependency injection (DI) and usage of IoC.
You use the simplest version of Service Locator pattern - container instance itself.
I suggest you use 'constructor injection'. You can find more information here (ASP.NET MVC 4 Dependency Injection).
public class CustomerController : Controller
{
private readonly IUnitOfWork unitOfWork;
private readonly ICustomerRepository customerRepository;
public CustomerController(
IUnitOfWork unitOfWork,
ICustomerRepository customerRepository)
{
this.unitOfWork = unitOfWork;
this.customerRepository = customerRepository;
}
public ActionResult List()
{
return View(customerRepository.Query());
}
[HttpPost]
public ActionResult Create(Customer customer)
{
customerRepository.Add(customer);
unitOfWork.SaveChanges();
return RedirectToAction("List");
}
}
2. Unit of Work (UoW) scope.
I can't find lifestyle of IUnitOfWork and ICustomerRepository. I am not familiar with Unity but msdn says that TransientLifetimeManager is used by default. It means that you'll get a new instance every time when you resolve type.
So, the following test fails:
[Test]
public void MyTest()
{
var target = new UnityContainer();
target.RegisterType<IUnitOfWork, EntityFrameworkUnitOfWork>();
target.RegisterType<ICustomerRepository, CustomerRepository>();
//act
var unitOfWork1 = target.Resolve<IUnitOfWork>();
var unitOfWork2 = target.Resolve<IUnitOfWork>();
// assert
// This Assert fails!
unitOfWork1.Should().Be(unitOfWork2);
}
And I expect that instance of UnitOfWork in your controller differs from the instance of UnitOfWork in your repository. Sometimes it may be resulted in bugs. But it is not highlighted in the ASP.NET MVC 4 Dependency Injection as an issue for Unity.
In Castle Windsor PerWebRequest lifestyle is used to share the same instance of type within single http request.
It is common approach when UnitOfWork is a PerWebRequest component. Custom ActionFilter can be used in order to invoke Commit() during invocation of OnActionExecuted() method.
I would also rename the SaveChanges() method and call it simply Commit as it is called in the example and in the PoEAA.
public interface IUnitOfWork : IDisposable
{
void Commit();
}
3.1. Dependencies on repositories.
If your repositories are going to be 'empty' it is not needed to create specific interfaces for them. It is possible to resolve IRepository<Customer> and have the following code in your controller
public CustomerController(
IUnitOfWork unitOfWork,
IRepository<Customer> customerRepository)
{
this.unitOfWork = unitOfWork;
this.customerRepository = customerRepository;
}
There is a test that tests it.
[Test]
public void MyTest()
{
var target = new UnityContainer();
target.RegisterType<IRepository<Customer>, CustomerRepository>();
//act
var repository = target.Resolve<IRepository<Customer>>();
// assert
repository.Should().NotBeNull();
repository.Should().BeOfType<CustomerRepository>();
}
But if you would like to have repositories that are 'layer of abstraction over the mapping layer where query construction code is concentrated.' (PoEAA, Repository)
A Repository mediates between the domain and data mapping layers,
acting like an in-memory domain object collection. Client objects
construct query specifications declaratively and submit them to
Repository for satisfaction.
3.2. Inheritance on EntityFrameworkRepository.
In this case I would create a simple IRepository
public interface IRepository
{
void Add(object item);
void Remove(object item);
IQueryable<T> Query<T>() where T : class;
}
and its implementation that knows how to work with EntityFramework infrastructure and can be easily replaced by another one (e.g. AzureTableStorageRepository).
public class EntityFrameworkRepository : IRepository
{
public readonly EntityFrameworkUnitOfWork unitOfWork;
public EntityFrameworkRepository(IUnitOfWork unitOfWork)
{
var entityFrameworkUnitOfWork = unitOfWork as EntityFrameworkUnitOfWork;
if (entityFrameworkUnitOfWork == null)
{
throw new ArgumentOutOfRangeException("Must be of type EntityFrameworkUnitOfWork");
}
this.unitOfWork = entityFrameworkUnitOfWork;
}
public void Add(object item)
{
unitOfWork.GetDbSet(item.GetType()).Add(item);
}
public void Remove(object item)
{
unitOfWork.GetDbSet(item.GetType()).Remove(item);
}
public IQueryable<T> Query<T>() where T : class
{
return unitOfWork.GetDbSet<T>();
}
}
public interface IUnitOfWork : IDisposable
{
void Commit();
}
public class EntityFrameworkUnitOfWork : IUnitOfWork
{
private readonly DbContext context;
public EntityFrameworkUnitOfWork()
{
this.context = new CustomerContext();
}
internal DbSet<T> GetDbSet<T>()
where T : class
{
return context.Set<T>();
}
internal DbSet GetDbSet(Type type)
{
return context.Set(type);
}
public void Commit()
{
context.SaveChanges();
}
public void Dispose()
{
context.Dispose();
}
}
And now CustomerRepository can be a proxy and refer to it.
public interface IRepository<T> where T : class
{
void Add(T item);
void Remove(T item);
}
public abstract class RepositoryBase<T> : IRepository<T> where T : class
{
protected readonly IRepository Repository;
protected RepositoryBase(IRepository repository)
{
Repository = repository;
}
public void Add(T item)
{
Repository.Add(item);
}
public void Remove(T item)
{
Repository.Remove(item);
}
}
public interface ICustomerRepository : IRepository<Customer>
{
IList<Customer> All();
IList<Customer> FindByCriteria(Func<Customer, bool> criteria);
}
public class CustomerRepository : RepositoryBase<Customer>, ICustomerRepository
{
public CustomerRepository(IRepository repository)
: base(repository)
{ }
public IList<Customer> All()
{
return Repository.Query<Customer>().ToList();
}
public IList<Customer> FindByCriteria(Func<Customer, bool> criteria)
{
return Repository.Query<Customer>().Where(criteria).ToList();
}
}
The only con I see is that you are highly dependent on your IOC tool, so make sure your implementation is solid. However, this is not unique to Onion designs. I have used Onion on a number of projects and have not run into any real 'gotchas".
I see couple of serious problems in code.
The 1st problem is relashionship between repositories and UoW.
var unitOfWork = container.Resolve<IUnitOfWork>();
var customerRepository = container.Resolve<ICustomerRepository>();
Here is implicit dependency. Repository will not work itself without UoW! Not all repositories needs to be connected with UoW. For example what about stored procedures? You have stored procedure and you hide it behind repository. Stored procedure invokation uses separate transaction! At least not in all cases. So if I resolve the only repository and add item then it will not work. Moreover this code will not work if I set Transient life license because repository will have another UoW instance. So we have tight implicit coupling.
The 2nd problem you create tight coupling between DI container engine and use it as service locator! Service locator is not good approach to implement IoC and aggregation. In some case it is anti pattern. DI container should be used
Here is my design of domain model and generic repository
public interface IEntity
{
long Id { get; }
}
public interface IRepository<T> where T : class, IEntity, new()
{
void Save(T entity);
void Delete(long id);
T Get(long id);
IEnumerable<T> GetAll();
}
public interface IUserRepository : IRepository<User>
{
User Login(string username, string password);
}
public class User : IEntity
{
// Implementation of User
}
public abstract class BaseRepository<T> : IRepository<T> where T : class, IEntity, new()
{
// Implementation of IRepository
}
public class UserRepository : BaseRepository<User>, IUserRepository
{
// Implementation of IUserRepository
// Override BaseRepository if required
}
When I want to instantiate a repository instance I use a factory which implements following interface
public interface IRepositoryFactory
{
R CreateRepository<R, T>()
where R : IRepository<T>
where T : class, IEntity, new();
}
And use the factory object as below
1. IRepositoryFactory factory = CreateFactory();
2. IUserRepository repository = factory.CreateRepository<IUserRepository, User>();
3. User user = repository.Login("user", "1234");
My problem is in the second line. I would like to use my factory like.
// Without specifying the User type parameter
factory.CreateRepository<IUserRepository>()
Since my IRepository interface has contstraint on type of entity my factory uses same constraint to satisfy IRepository requirement.
Is there any way to isolate this parameter from client?
I agree with the others that you would benefit from looking at a DI/IoC framework like Ninject.
So this answer is not a suggestion to not follow the other advices. But still, there are ways for you to solve your problem at a lower level. This code is not tested very well, but you could do something like this:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;
using NUnit.Framework;
namespace TestConsole1
{
public interface IEntity
{
long Id { get; }
}
public interface IRepository<T> where T : class, IEntity, new()
{
void Save(T entity);
void Delete(long id);
T Get(long id);
IEnumerable<T> GetAll();
}
public interface IUserRepository : IRepository<User>
{
User Login(string username, string password);
}
public class User : IEntity
{
// Implementation of User
public long Id
{
get { return 42; }
}
}
public abstract class BaseRepository<T> : IRepository<T> where T : class, IEntity, new()
{
// Implementation of IRepository
public void Save(T entity)
{
throw new NotImplementedException();
}
public void Delete(long id)
{
throw new NotImplementedException();
}
public T Get(long id)
{
throw new NotImplementedException();
}
public IEnumerable<T> GetAll()
{
throw new NotImplementedException();
}
}
public class UserRepository : BaseRepository<User>, IUserRepository
{
// Implementation of IUserRepository
// Override BaseRepository if required
public User Login(string username, string password)
{
return new User();
}
}
class Factory
{
public T CreateRepository<T>() where T : class
{
//TODO: Implement some caching to avoid overhead of repeated reflection
var abstractType = typeof(T);
var types = AppDomain.CurrentDomain.GetAssemblies().ToList()
.SelectMany(s => s.GetTypes())
.Where(p => p.IsClass &&
!p.IsAbstract &&
abstractType.IsAssignableFrom(p));
var concreteType = types.FirstOrDefault();
if (concreteType == null)
throw new InvalidOperationException(String.Format("No implementation of {0} was found", abstractType));
return Activator.CreateInstance(concreteType) as T;
}
}
class Program
{
static void Main(string[] args)
{
var factory = new Factory();
var userRepo = factory.CreateRepository<IUserRepository>();
Console.WriteLine(userRepo.GetType());
User user = userRepo.Login("name", "pwd");
Console.WriteLine(user.Id);
Console.ReadKey();
}
}
}
As this code reveals, a central point is that you will need to handle the coupling between your interface and the concrete class, for example between your IUserRepository and your UserRepository. If you do not handle this relation in a direct way via a mapper or similar you can implement a more automatic way like the one that is illustrated in the code.
However, if you use something like Ninject instead to handle this for you, it will be a better investment of your time as you will most likely find that the complexity of your factory class will grow significantly over time.
Br. Morten
There are 3 problems with your code:
First is IEntity. Having single type of ID is against DDD, because in DDD, identity of object is given by domain and it can be anything from string, int, guid to complex type.
Second is generic repository with IRepository, which again, is highly useless, because you will rarely pass this interface and mostly will pass interface for repository for concrete entity.
Third thing is that in DDD repositories should exist only for aggregate roots, which is not reflected in your design.
If you fix this, you will find out, that implementation of interface of repository for specific entity can easily be suplied by DI framework.
I have a bunch of Repository classes which all look a bit like the following. Note that I have omitted certain methods; I just want you to get a flavour.
public class SuggestionRepository : ISuggestionRepository
{
private IUnitOfWork _unitOfWork;
public SuggestionRepository(IUnitOfWork unitOfWork)
{
_unitOfWork = unitOfWork;
}
public Suggestion Load(int id)
{
Suggestion suggestion;
suggestion = _unitOfWork.Load<Suggestion>(id);
return suggestion;
}
public IQueryable<Suggestion> All
{
get { return _unitOfWork.GetList<Suggestion>(); }
}
}
You'll imagine the amount of repeated code I have between my repositories.
I would like to create a Repository<T> class which is extended by my repositories so that hopefully I don't have to write boilerplate code for each one. This class might look something like the following:
internal class Repository<T> where T : Entity
{
private IUnitOfWork _unitOfWork;
internal Repository<T>(IUnitOfWork unitOfWork)
{
_unitOfWork = unitOfWork;
}
public T Load(int id)
{
T t;
t = _unitOfWork.Load<T>(id);
return t;
}
public IQueryable<T> All
{
get { return _unitOfWork.GetList<T>(); }
}
}
But Visual Studio isn't showing that constructor any love at all. It's saying 'unexpected token' around the parameter list brackets, saying it can't access the non-static field _unitOfWork in a static context, and pretending it doesn't know what the parameter unitOfWork is.
Clearly generic classes can have constructors as it's possible to new up a List<T> for example. So what's going on?
The constructor for a generic class should not have the type arguments in the method name. Simply say
internal Repository(IUnitOfWork unitOfWork)
and see how you get on.
You can't specify <T> on the constructor, it's implied by the fact that the class operates on generic type T