7

I am using Dependency Injection for a .NET MVC web application in which I have three basic layers:

1) Web App 2) Service Layer 3) Data Layer

I inject the data layer into the service layer and the service layer into a controller in my web app which is all fine but I am confused over where the registering of these classes takes place.

After researching I've been told that the composition root is within the web application specifically in the Global.asax file which I have in my project, but this means that now I have a reference to the Data Layer within the web application in order to be able to register it. This seems to go against exactly what DI is for to me as I don't want my web app to know or care about the data layer only the service layer should have a reference?

Improve this question
4
  • Usually the database name etc would be set up in web.config, and possibly used in global.asax. But certainly you would want to avoid hard-coding setup information like that. But it is needed by the "top" of the application stack in some form.
    – ebyrob
    Oct 20, 2015 at 16:02
  • "only the service layer should have a reference" Why?
    – Ben Aaronson
    Oct 20, 2015 at 16:12
  • Well I guess that is my miss-understanding. My thoughts were and this is because people generally say this but I shouldn't have to touch the Web Application to swap to a new DB for example but I assume now you would still need to remove the old reference, add the new reference then change the DI Container code and re-compile?
    – Simon Nicholls
    Oct 20, 2015 at 16:37
  • @SimonNicholls You should have to "touch" as in change a config value in the web app to change databases, but not necessarily recompile or change any code.
    – ebyrob
    Oct 20, 2015 at 19:52

1 Answer 1

Reset to default
11

Does Having DI Happen in the Composition Root go against the whole point of Dependency Injection?

No. You should create the object graph in the Composition Root.

I think that I understand the reason of your confusion. And I think that it is related to ASP.NET projects. To explain this, let me give first an example that does not involve ASP.NET.

Let's say we have a Console Application. We have created some class libraries that contain all the pieces of logic that our application need.

Let's say we created the following class libraries:

  1. ApplicationLibrary contains classes that are related to the application itself. It might contain some UI logic also.
  2. BusinessLogicLibrary contains classes related to business logic.
  3. DataAccessLibrary contains classes related to data access.

The ApplicationLibrary in this case does not have a reference to the DataAccessLibrary.

And then we compose these pieces together in the Console Application project. This project in this case does not contain anything except the composition root.

The thing with the ASP.NET projects is that by default we get a template in which the composition root and some Application/UI logic are in the same project.

What would be great is to have an ASP.NET web project that contains only the composition root (IControllerFactory implementation for example). And then move our Controllers and Views to another class library that does not have a reference to the DataAccessLayer since it is no longer the composition root.

You might even be able to do this with ASP.NET. I am not sure if there is an easy way though.

Improve this answer
1
  • This is exactly what I mean thank you - it just seemed/seems a bit of a stupid place to put the composition root in my opinion.
    – Simon Nicholls
    Oct 27, 2015 at 11:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.