IoC and "hiding implementation details"

Question

I implemented DI in my project through constructor injection, now the composition root is where all resolving takes place (this is, at the web project), and my question is whether the idea of creating an additional project that just handles the resolving is insane.

The reasoning behind this is while I would still have the implementation assemblies in the build directory (because they would still be referenced by the "proxy" project), I wouldn't need to reference them at web project level, which in turn would mean that the implementation of these interfaces wouldn't be accessible from somewhere other than where they're implemented (unless explicitly referenced, which would quickly pinpoint that something is wrong: you don't want to be doing this).

Is this a purposeless effort likely to become error prone or is it a reasonable thing to do?

Answer 1

You could do some post-build processing to ensure the implementation doesn't leak out.

Cheers Tymek

Answer 2

This is not insane at all - it is a very good litmus test to make sure no dependencies have sneaked in and very useful as such. This would only work though if your abstractions / interfaces are defined in a different assembly than the concrete classes that implement those interfaces.

Having said that, personally I have always kept the aggregate root within the main web app assembly, there is extra effort involved in this extra assembly and since I for the most part only inject interfaces I am not too worried about it, since my main concern is really testability. There might be projects though for which this is a worthwhile approach.

Answer 3

There are pros and cons of this. As BrokenGlass said, this is a litmus test, on the flip side you really have to be careful you deploy all of the assemblies. Since dependencies of included libs are not put into the bin folder of the web app, you'll need to ensure they aren't missed although upon first run you would experience this and the resolution would ideally be easy.

This is indeed a matter of personal preference, for ease I like to include in the web app, but again, it can ensure those dependencies don't leak to the web app. However if your project is organized in such as way where your controllers always inject what you require, then the chances of it happening are less. For ex, if you take IContext in every controller then you are less likely to use using(var context = new Context()) in your app, since the standard has been set.