无法使用Autofac解析已注册类型的键控通用参数

Question

This question if sort of an extension or replacement to my earlier question Unable to resolve AutoFac Keyed service with KeyFilterAttribute not working

So, I have a generic UnitOfWork pattern. In my earlier question the IUnitOfWork interface was a generic interface. However, I realized that the generic type parameter TContext of IUnitOfWork was of no use. So I decided to strip my IUnitOfWork of the generic parameter.

However, the problem mentioned in my earlier question still exists - wrong type of DbContext is being assigned to the _dbContext property of UnitOfWork. With this code, I cannot explicitly specify the context on the service dependency as it is no longer a generic interface. So the only solution is to depend on Autofac keyed service. Could someone help me this problem.

Below are the new code snippets for my modified code:

Non-generic IUnitOfWork interface:

public interface IUnitOfWork

Generic UnitOfWork class:

public sealed class UnitOfWork<TContext> : IDisposable, IUnitOfWork where TContext : IDbContext
    {
        private static readonly ILog Log = LogManager.GetLogger(typeof(UnitOfWork<TContext>));

        private readonly IDbContext _dbContext;
        private Dictionary<string, IRepository> _repositories;
        private IDbTransaction Transaction { get; set; }

        public UnitOfWork(IDbContext context)
        {
            _dbContext = context;
        }
    }

Autofac registrations:

builder.RegisterType<CommentsService>().As<ICommentsService().WithAttributeFiltering();

builder.RegisterType<ReconciliationDbContext>().As<IDbContext>();
builder.RegisterType<GenevaDataDbContext>().As<IDbContext>();
builder.RegisterType<OpenStaarsDbContext>().As<IDbContext>();

builder.RegisterType<UnitOfWork<ReconciliationDbContext>>().Keyed<IUnitOfWork>(ContextKey.Recon).InstancePerLifetimeScope();
builder.RegisterType<UnitOfWork<OpenStaarsDbContext>>().Keyed<IUnitOfWork>(ContextKey.OpenStaars).InstancePerLifetimeScope();

CommentsService class:

public class CommentsService : ICommentsService
{
        private readonly IUnitOfWork _reconciliationUoW;

        public CommentsService([KeyFilter(ContextKey.Recon)]IUnitOfWork reconciliationUoW)
        {
            _reconciliationUoW = reconciliationUoW;
        }
}

Answer 1

You're going to have to use keyed services all the way down if you aren't going to make IDbContext generic. There are a few things you need to consider when you're designing deep levels of things in DI.

Note: This is an FAQ on the Autofac site but I'll try and unwrap a couple of things here to help out.

Concept 1: Last In Wins

The point of being able to register different types with the same interface is for two purposes:

• You need to resolve a list of those things (eg, IEnumerable<IDbContext> ) OR
• You are overriding the default thing being resolved.

Your registrations here...

builder.RegisterType<ReconciliationDbContext>().As<IDbContext>();
builder.RegisterType<GenevaDataDbContext>().As<IDbContext>();
builder.RegisterType<OpenStaarsDbContext>().As<IDbContext>();

...say two things:

• If I resolve IEnumerable<IDbContext> I want these three things instantiated and handed back to me.
• If I resolve a single IDbContext I want a ReconciliationDbContext ... no, wait, I really want a GenevaDataDbContext ... no, I meant I want an OpenStaarsDbContext . Yes. Any time I resolve a single IDbContext I want OpenStaarsDbContext .

Concept 2: Interface Consumers Don't Know About Underlying Implementations

The whole point of interface vs. implementation is so you don't know what the underlying implementation is. This is the Liskov Substitution Principle. If UnitOfWork<ReconciliationDbContext> must have a ReconciliationDbContext and can only work with that type... then put ReconciliationDbContext in the constructor for that class and don't use an interface. Full stop. If you must have a specific type and can't treat all IDbContext types the same, then there's a design problem.

Concept 3: Seriously, Interface Consumers Don't Know About Underlying Implementations

At some point along the way of trying to figure out how to make this work down the stack you'll think, "Hey - I could pass a parameter to the unit-of-work class and have that passed all the way down the resolve stack and set some sort of 'context' that..." NO. This is also an FAQ. You can't do that because, again, you shouldn't know or care about what the whole chain of the resolve stack is. If you need that, you're not using DI or "inverting control" - you may as well new-up everything the old way.

--

Again, this is an FAQ on the Autofac site and I recommend reading through to understand in more depth why what you're asking for is going to be kind of difficult and why, in some cases, it's intentionally difficult.

However, if you want to use keyed services, you'll have to do it literally all the way down the stack.

CommentService is fine, but you'll also need stuff like...

public class ReconciliationUnitOfWork : UnitOfWork<ReconciliationDbContext>
{
  public ReconciliationUnitOfWork([KeyFilter(ContextKey.Recon)]IDbContext context)
  { /* ... */ }
}

And then you'll have to update your registrations to enable the filtering like...

builder.RegisterType<ReconciliationDbContext>()
       .Keyed<IDbContext>(ContextKey.Recon);
builder.RegisterType<ReconciliationUnitOfWork>()
       .Keyed<IUnitOfWork>(ContextKey.Recon)
       .InstancePerLifetimeScope();

Yeah, that's painful. You can make it a little easier by not defaulting to the same interface everywhere.

public class ReconciliationUnitOfWork : UnitOfWork<ReconciliationDbContext>
{
  public ReconciliationUnitOfWork(ReconciliationDbContext context)
    : base(context)
  { /* ... */ }
}

Then you don't have the keyed stuff for the database contexts, but you'll have to do...

builder.RegisterType<ReconciliationDbContext>()
       .AsSelf()
       .As<IDbContext>();
builder.RegisterType<ReconciliationUnitOfWork>()
       .Keyed<IUnitOfWork>(ContextKey.Recon)
       .InstancePerLifetimeScope();

OK, now you can still resolve all the IDbContext objects if you need, but you can also resolve ReconciliationDbContext as a concrete type to support the new ReconciliationUnitOfWork there.

How can you make it even more generic? Add the generics back in that you said you removed from your other question. UnitOfWork<TContext> should have a constructor parameter of type TContext instead of IDbContext . You could add a constraint, like:

public class UnitOfWork<TContext> where TContext : IDbContext

Now you're assured to get an IDbContext implementation but it'll be a strong type, which is what you need.

You could then make it even more generic by not bothering with registering every combination of contexts and types.

builder.RegisterGeneric(typeof(UnitOfWork<>))
   .AsSelf()
   .InstancePerLifetimeScope();

And then CommentsService should take the exact type of unit of work because it, too, isn't able to use just any old unit of work interchangeably.

public class CommentsService : ICommentsService
{
  public CommentsService(UnitOfWork<ReconciliationDbContext> reconciliationUoW)
  { /* ... */ }
}

Now you're actually using the type system and not breaking Liskov Substitution Principle. Your life will be easier and you'll get what you want.