When using inversion of control in a .Net application, is it acceptable to add a reference to your data layer in your host application?
Say I have the following individual projects:
- MyApp.Data (EF classes)
- MyApp.Business (Service factory / repository)
- MyApp.Services.MyWCFService (Host)
- MyApp.Presentation.MVC (Host)
- MyApp.Business.Tests (Host)
In this situation, I have historically used IoC between MyApp.Business and the host apps – creating interfaces for each service factory / repository, and using DI in the host application. Each application then has the choice to inject its own implementation of my business factories. I’ve never had an issue with this, as my host apps only ever rely on the business layer, and I never have to reference the MyApp.Data assembly (my MyApp.Business generally deals with all calls to the MyApp.Data assembly, and renders the results in to composite business objects).
What I’m trying to achieve with my latest project is to use IoC at every level – i.e. creating interfaces in MyApp.Data, so I can apply mocking and proper unit tests to MyApp.Business. It seems to me that the only way to achieve this is to create an assembly reference to both MyApp.Business and MyApp.Data in the host application, then use DI to inject both the MyApp.Data and MyApp.Business implementations.
This is contrary to everything I’ve been taught with conventional nTier applications, though I understand that it’s DI that’s doing all the work, and the reference is basically for resolution only. Am I right in assuming this is the right way to approach it? Is there a better way?
In short: Yes, it is acceptable to reference each and any part of your app from the main entry point of your application.
The concept is called Composition Root.