Does Dependency Injection violate the Separation of Concerns as it pertains to an n-tier architecture?
Suppose you have the following projects:
MyApp.Data
MyApp.Business
MyApp.Web
If I were to use DI to tell the Business Layer which Data Context to use, wouldn't this violate SoC? This would mean the UI (MyApp.Web) would have to have knowledge of the Data Access Layer (MyApp.Data) to tell the Business Layer (MyApp.Business) which context to use, right?
public class WebForm {
public void Save(Object dto) {
BusinessObject bo = new BusinessObject(Data.MyDataContext);
bo.ValidateAndSave(dto);
}
}
I always thought, in an n-tier architecture, each tier should only have knowledge of the next tier (UI to Business, Business to Data). Is this not really a big deal?
In general, you're correct. However, Dependency Injection tends to be thought of as "configuration" rather than part of the Presentation Layer (even though it often typically does live there). If your UI components are designed to not know about the data layer, then this is what really matters.
If you are designing a testable system, then the business and data layers should be independent of the UI, but something has to configure them. You could create yet another layer, called MyApp.Configuration that does all this, but most people find this to be over-engineering.
The important thing is whether your components are well designed, not whether the UI has some configuration knowledge of the other layers.
It's really no different from having app settings in your Web.Config. After all, unless your using a service oriented architecture, everything is running on the same computer in the same process anyways. And if you are using an SoA, then you would configure the individual parts on their respective servers.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With