2

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?

bevacqua
  • 47,502
  • 56
  • 171
  • 285
  • I'm not clear on the purpose of the "proxy" project. It seems like it's to remove direct dependencies form the web app to the implementations, and that the goal is a plugin model. However, if this is the case, you're just adding a level of indirection. Have you considered using MEF to do the composition of implementations from external assemblies that are not known at compile time? It's designed to do this. – jonsequitur Mar 01 '12 at 03:48
  • 2
    Related: http://stackoverflow.com/questions/9501604/ioc-di-why-do-i-have-to-reference-all-layers-assemblies-in-entry-application/9503612#9503612 – Mark Seemann Mar 01 '12 at 07:21

3 Answers3

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.

BrokenGlass
  • 158,293
  • 28
  • 286
  • 335
2

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.

Adam Tuliper
  • 29,982
  • 4
  • 53
  • 71
  • 1
    That's a good point about the deploy complications. Like many, I see the "purity" of doing your DI mapping somewhere else, but in practice it's just not worth it. – Erik Funkenbusch Mar 01 '12 at 04:00
  • @Mystere that's exactly the balance I'm questioning here, "is it worth it?" is the question, "do the benefits outweight the downsides?" – bevacqua Mar 01 '12 at 04:04
  • @Nico - only you can answer that. I personally do not find it worth it. It sounds like Adam and BrokenGlass don't either (but I don't want to put words in their mouth). But I know lots of people that do things I don't think is worth it, because to them it is. – Erik Funkenbusch Mar 01 '12 at 04:08
0

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

Cheers Tymek

tymtam
  • 31,798
  • 8
  • 86
  • 126