search

cwilby / acme-architecture

An example ASP Web API project developed to .NET best practices.
20 stars 7 forks source link

Support multiple DbContext #2

Open pfaustinopt opened 5 years ago

pfaustinopt commented 5 years ago

Hello again,

I was trying a different strategy with your architecture, which is separating the DbContext into multiple DbContexts (I'm trying to apply some DDD patterns).

However, I'm not having an easy time with IUnitOfWork because it is coupled with the AcmeDataContext. I was thinking about creating a IUnitOfWork where T could be a DbContext, but this means that the Core layer would need to have a reference to Entity Framework, which I was avoiding.

Do you have any ideas on how to decouple IUnitOfWork from AcmeDataContext while still being capable of using IoC to register multiple DbContexts?

cwilby commented 5 years ago

Hmm.

Off the top of my head, we could change UnitOfWork.DataContext to be of type DbContext because the only method call there is SaveChanges.

We could then implement a second IDatabaseFactory that returns your second context.

Then we could utilize something like context based injection to differentiate between the unit of works.

That, or make UnitOfWork a generic class to specify the type of DatabaseFactory it should inject.

Thoughts?

pfaustinopt commented 5 years ago

My mistake!

Your first idea is great, I didn't know the context based injection concept as I'm using autofac (I'll have to check if they have a similar approach, because the other solutions they present end up leaking the IoC container into the Core Layer).

If I'm understanding correctly, the second approach means that the IDatabaseFactory needs to go on the Core Layer so we can have something like this IUnitOfWork<T> where T: IDatabaseFactory

However, the current interface of IDatabaseFactory leaks DbContext with the GetDataContext() method. Am i missing anything?

cwilby commented 4 years ago

@pfaustinopt Sorry for the delay in response - you're right, IDatabaseFactory does leak the DbContext, I'm not sure what can be done here.

This StackOverflow question discusses a lack of IDbContext, and suggests relying on inheritance instead of composition.

Otherwise, other options include replacing Entity Framework with Dapper or options I haven't considered yet.