Too much dependency injection for web app and web service layer?

Question

We have a website application and a web services layer. The website must use the web service for data per our requirements. Both layers are being build by me. I'm curious if my layout for DI is justified.

Common entities project - shared by both the website and web service layer

ASP.NET MVC website -- MVC service layer - injects concrete class to contain business rules for the website/pages -- -- Data repository - injected by MVC service layer. In this case, various wrappers for web service calls currently, but things may change

Web services -- Service/business layer - injected classes to handle business logic for services -- -- Data repository - injected data classes used by business layer above. Can be ADO or EF.

So, any call can be up to 4 layers of injection. I see benefit in this, as each part can be isolated and tested. In some cases, the business layers can just "pass through" to the data layer (e.g., GetClientByID(int id) has little logic), but are there in case rules change. I feel the injections for the data layer abstract away any auto-generated entities from the web services. Luckily, in my case currently, it shares a common project, but who knows if this stays that way.

Is this too much? Thanks.

Answer 1

Your question is highly subjective, but I will try to answer it anyway.

You are breaking your application into logical tiers that can each be unit tested. This is generally a good thing. Different abstraction points or interfaces mean that you can easily swap the logic if you need to down the road, which makes the application more extensible and maintainable.

Is it too much?

That really depends on several factors - deadlines, budget, the life expectancy of the project, etc. The more layers you need to build, the bigger the upfront investment and the more layers you need to maintain later. But the abstractions make it easier to swap business logic - which often makes it worth the upfront cost.

But is it too much for your DI container to handle? No. Keep in mind the purpose of DI is to simplify application complexity. The more layers and services you have, the more it makes sense to use DI. DI makes it so your application layers and services don't depend directly on each other so they can be replaced without too much effort. Also, if you use a Composition Root pattern and use constructor injection, DI generally has very low overhead so performance is almost never a factor.