How to Inject Open Connections with an IoC

Question

First, my scenario. I have a service, BillingService, has a constructor like this:

BillingService(IInstallmentService, IBillingRepository)

The InstallmentService has a constructor that looks like this

InstallmentService(IBillingRepository, IInstallmentCalculator)

My Billing service is an application service and the methods will coordinate the operation between the moving pieces. Everything is registered in my IoC container so that my facade only has to resolve an IBillingService and call the operation.

My BillingService and installment service both need to access the BillingRepository. I should only have to open one DB connection, so ideally the BillingRepository would take an IDbCOnnection in the constructor.

My question is, how do I get an open connection passed into my BillingRepository from my container and then effectively close it after my BillingService is done with it? I'm stuck with Unity at this client. If I were writing this by hand, it would looke like this:

using(IDbConnection conn = DbFactory.GetConnection())
{
     IBillingRepository repo = new BillingRepository(conn);
     IInstallmentCalculator calc = new InstallmentCalculator();
     IInstallmentService installmentService = new InstallmentService(repo,calc);
     IBillingService billService = new BillingService(installmentService, repo);

     billService.DoSomething(parameters);

}

Answer 1

Hi,

I don't have much experience with Unity, but I would keep connection details to your BillingRepository and pass the open connection via a property to your other objects.

So in your container create a property that returns a BillingRepository object and then you can access your open connection through that property in any other object.

Answer 2

I'd introduce a dependency on the connection into the BillingRepository, just like in your example, but let Unity create the connection.

Make sure BillingRepository implements IDisposable (possibly the billing service too), and set it up as a transient object (however that's expressed in Unity).

If the billing repository maintains some state that needs a longer lifetime (for example, for the life of the application), I'd factor that out into another class and make the billing repository dependent on that too.