I have a medium sized asp.net MVC app. It consumes a service layer that handles all the repository use, calling domain services, etc. My controller actions are very slim — they basically call a service class, get a response and show that respose. Most components are interface based with some poor man’s DI. The app is growing, needs better testing support, and starting to call out for an IoC container.
Everything I read (such as this SO question) states that I should configure the IoC at the application root. This makes sense to me if I were using repositories right from my controller actions and needed DI at the controller level, but I’m not. It seems like I’d want my composition root in my service layer. I keep thinking that I don’t want my web.config (or another config) at the UI layer even mentioning/seeing/hearing about a repository, credit card processor, etc.
Am I thinking about this the right way or do I just need to get over it?
You just need to get over it 🙂
Having your Composition Root in the application root doesn’t require you to have a lot of DI Container stuff in web.config. You can if you will, but it’s optional. What is not optional when putting the Composition Root in the application root is that you need to have some DI code in Global.asax.
You may find it irrelevant because your Controllers are so thin, but that’s not the real point. The actual point is that you (the abstract ‘you’) want to postpone coupling classes until the last responsible moment. The earlier you couple types, the less flexibility you have.
If you couple classes in the service layer, you make an irreversible decision at that point. If it later turns out that you need to compose those services differently, you can’t – not without recompiling, that is.
If there was a major benefit of doing it, I can understand why you would want to, but there isn’t. You may as well wait composing all components untill you absolutely must do so – and that’s in the application’s entry point.