7

I am trying to decouple my unit of work from my services or repository so that I wont have to touch the UoW code whenever I wish to add a new service. How do I do this?

_categoryService = _unitOfWork.Get<ICategoryService>();

so instead of

_unitOfWork.CategoryService.Add(category)

I can just say;

_categoryService.Add(category);
tereško
  • 58,060
  • 25
  • 98
  • 150
secretAgentB
  • 1,279
  • 4
  • 19
  • 36
  • Can you elaborate more about your scenario? It seems to me that you are talking about injection of dependency (your code depends on ICategoryService and you want to inject it automatically), but it is not clear from your question. – Goran Obradovic Mar 03 '13 at 09:38
  • Hi! I have an MVC4 test project to study the UoW pattern. I have a controller, a service class that references the repository. But as you can see I have this CategoryService in my UoW as a property. Then I realized that whenever I create a new service for something in the future I'd have to add this service to the UoW class I have. I am trying to find a way to just have a Get function that returns a service type based on what interface i passed to it. Im not even sure if this is the right way to go about this. Thanks! – secretAgentB Mar 03 '13 at 18:34
  • What are you using for UoW container? You should use some of the IoC's, check this page for nice list: http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersIOC.aspx Most of them have .Resolve() method, or similar, and you can register most of them as default dependency resolver in asp.net mvc, so you just add IService as parameter to your controller. Is this what are you asking? – Goran Obradovic Mar 03 '13 at 18:48

1 Answers1

18

I am trying to decouple my unit of work from my services or repository so that I won’t have to touch the UoW code whenever I wish to add a new service

Well, that’s a good start! ;-)

The solution I am presenting is not the one and only possible solution, there are several good ways to implement UoW (Google will help you out). But this should give you the big picture.

First, create 2 interfaces: IUnitOfWork and IRepository

public interface IUnitOfWork : System.IDisposable
{
  IRepository<TEntity> GetRepository<TEntity>() where TEntity : class;
  void Save();
}

public interface IRepository<T> : IDisposable where T : class
{
  void Add(T entity);
  void Delete(T entity);
  void Update(T entity);
  T GetById(long Id);
  IEnumerable<T> All();
  IEnumerable<T> AllReadOnly();
  IEnumerable<T> Find(Expression<Func<T, bool>> predicate);
} 

The implementations are quite straightforward (I removed all my comments for readability purpose, but do not forget to add yours ;-) )

public class UnitOfWork<TContext> : IUnitOfWork where TContext : IDbContext, new()
{
  private readonly IDbContext _ctx;
  private Dictionary<Type, object> _repositories;
  private bool _disposed;

  public UnitOfWork()
  {
    _ctx            = new TContext();
    _repositories   = new Dictionary<Type, object>();
    _disposed       = false;
  }

  public IRepository<TEntity> GetRepository<TEntity>() where TEntity : class
  {
    if (_repositories.Keys.Contains(typeof(TEntity)))
      return _repositories[typeof(TEntity)] as IRepository<TEntity>;

    var repository = new Repository<TEntity>(_ctx);
    _repositories.Add(typeof(TEntity), repository);
    return repository;
  }

  public void Save()
  {
     try
     {
       _ctx.SaveChanges();
     }
     catch (DbUpdateConcurrencyException ex)
     {
       ex.Entries.First().Reload();
     }
  }

  …
}

public class Repository<T> : IRepository<T> where T : class
{
  private readonly IDbContext _context;
  private readonly IDbSet<T> _dbset;

  public Repository(IDbContext context)
  {
    _context = context;
    _dbset   = context.Set<T>();
  }

  public virtual void Add(T entity)
  {
    _dbset.Add(entity);
  }

  public virtual void Delete(T entity)
  {
    var entry = _context.Entry(entity);
    entry.State = EntityState.Deleted;
  }

  public virtual void Update(T entity)
  {
    var entry = _context.Entry(entity);
    _dbset.Attach(entity);
    entry.State = EntityState.Modified;
  }

  public virtual T GetById(long id)
  {
    return _dbset.Find(id);
  }

  public virtual IEnumerable<T> All()
  {
    return _dbset.ToList();
  }

  public virtual IEnumerable<T> AllReadOnly()
  {
    return _dbset.AsNoTracking().ToList();
  }

  public IEnumerable<T> Find(Expression<Func<T, bool>> predicate)
  {
    return _dbset.Where(predicate);
  }

}

As you can see, both implementations make use of IDbContext interface. This interface is just for easy testing purpose:

public interface IDbContext
{
  DbSet<T> Set<T>() where T : class;
  DbEntityEntry<T> Entry<T>(T entity) where T : class;
  int SaveChanges();
  void Dispose();
}

(As you can see, I’m using EntityFramework Code First)

Now that the whole plumbing is set up, let’s have a look at how this could be used in a service. I have a base service that looks like this:

internal class Service<T> where T : class
{
  internal Service(Infrastructure.IUnitOfWork uow)
  {
    _repository = uow.GetRepository<T>();
  }

  protected Infrastructure.IRepository<T> Repository
  {
    get { return _repository; }
  }

  private readonly Infrastructure.IRepository<T> _repository;
}

And all my services inherit from this base service.

internal class CustomerService : Service<Model.Customer>
{
  internal CustomerService(Infrastructure.IUnitOfWork uow) : base(uow)
  {   
  }

  internal void Add(Model.Customer customer)
  {
    Repository.Add(customer);
  }

  internal Model.Customer GetByID(int id)
  {
    return Repository.Find(c => c.CustomerId == id);
  }

}

And that’s it!

Now, if you want to share the same UoW to several services, in a facade method or somewhere else, it could just look like this:

using (var uow = new UnitOfWork<CompanyContext>())
{
  var catService = new Services.CategoryService(uow);
  var custService = new Services.CustomerService(uow);

  var cat = new Model.Category { Name = catName };
  catService.Add(dep);

  custService.Add(new Model.Customer { Name = custName, Category = cat });

  uow.Save();
}

Hope this helps!

MaxSC
  • 4,698
  • 2
  • 23
  • 36
  • Sorry, I just got back from a very long vacation. I'll try this out. Thanks a lot! – secretAgentB Apr 12 '13 at 14:52
  • Max, let me ask you a question. You defined Repository methods as virtual so you could override them. Where would you override them if you don't have any class that inherits from Repository (maybe I want a repository to delete in a particular way). I don't like the idea of extension methods but it's a way out. Would it be a way to work with classes that inherit from Repository (CustomerRepository for example) and override some methods and add new ones without the need of extension methods?? – snekkke Dec 13 '13 at 17:14
  • @snekkke Thanks for your feedback. Actually, you're right. Virtual is quite useless here. One way to customize things would be to add specific methods to your `services`. Adding that kind of methods could do the job: `internal Model.Customer GetByExternalIdAndChannelAsReadOnly(string externalCode, ChannelId channel) { var cust = Repository.Find(c => c.ExternalCode == externalCode && c.ChannelId == (byte)channel).SingleOrDefault(); return cust ; }` – MaxSC Dec 16 '13 at 10:35
  • Thanks Max, right now i'm trying to architect my app and i can´t find the architecture that makes me happy. I´m trying to use a service layer, unit of work, repositories, domain classes...but i can´t put all of them to work together....each time i added a new layer or new pattern i end up with something new (for example now i think i can't make any progress without a DI container)...do you have any thoughts on how could an acceptable architecture could be composed?? – snekkke Dec 16 '13 at 19:16
  • Well, it's quite impossible to decide or even advise you on what architecture to choose. The reason is that an architecture needs to address a business need. Without knowing your business I can't help you that much. What I can tell you, though, is to keep things simple. Start simple, then if needed, add some more abstraction and refactor. However, have a look at Jeffrey's Palermo Onion Architecture. I also answered to a lot of [SO Onion Architecture related questions](http://stackoverflow.com/search?tab=votes&q=user%3a1660523%20%5bonion-architecture%5d). – MaxSC Dec 17 '13 at 09:18
  • 1
    Thanks again!! I'll look those articles. One more question, in the method GetRepository of the UnitOfWork class you get new repositories by this line of code: "get var repository = new Repository(_ctx);". Is there a way to remove the reference to the Repository class so that it could be injected?? How could it be done? Or you have to explicitly tell your DI container to give you an instance for an IRepository type?? – snekkke Dec 17 '13 at 20:22