Review of Mark Sieman's book Dependency Injection in .NET

Opening a book on “newfangled design techniques”, such as dependency inversion, expect to see a description of another silver bullet. Say, here, before that we all lived wrong, and now, armed with a scrap container and some kind of mother, we can write new applications in 10 minutes.
Since I myself am somewhat cautious with such new-fangled tools, I was pleasantly surprised that in the book Mark focuses on generally accepted design practices, the role of standard design patterns, and indeed, considers the principles of dependency management in isolation from specific tools.


QUOTE
If you think that DI requires the use of DIcontainer, then this is another point that needs to be retrained. DI is a set of principles and patterns, and a DI container is a useful but optional tool.
Looking at the typical use of dependency inversion in many projects, one gets the impression that DI contradicts the basic design principles that Meyer and Butch write so much about .

For the sake of supposedly “loosely coupled design”, dozens of unnecessary interfaces are distinguished, the containers themselves are used in the role of Service Locators right and left, classes with a dozen constructor parameters are created, the required class dependencies are passed through properties, etc. Looking at all this, it seems that DI containers contradict things like class invariants and a clear contract between the class and its clients.

QUOTE
DI is not an end in itself. Dependency management leads to loose coupling , which leads to more maintainable code.
Mark begins by trying to dispel the basic myths about DI, and only then begins the description of the basic concepts. So, the author from the first pages says that the Service Locator is an anti-pattern and the container should be used only in one place, in the “root of the application” (in the so-called Composition Root ), it says that IOC! = DI, writes about problems with using configuration files to manage container content and more.

QUOTE
Don't expect DI containers to magically make your code loosely coupled. A DI container can make dependency management more efficient, but your application should be designed with DI techniques and principles in mind .

I was very pleased that the author set the main goal of the book not to consider specific libraries, but to emphasize the general principles of dependency management and to show the connection of these principles with standard design patterns and OO principles (after all, most of the classical design patterns use dependency management in one form or another : for example, the decorator uses Constructor Injection , and the strategy uses Method Injection or Constructor Injection, etc.).

During the first three parts, no containers are used at all, and all the examples use “self-made” dependency management (the so-called Poor Man's DI).

QUOTE
DI-container is just a tool, and like any tool, it can be used correctly, or it can be used incorrectly.

I was very pleased that, in addition to the principles and patterns themselves, the author describes when they are applicable and when not. Each pattern has its own field of application, one of them is suitable in one case and not suitable in another. And some patterns in general seem very attractive, but in fact it turns out that their use can lead to serious problems. It is for this reason that the whole part of the book is devoted to the main DI patterns and anti-patterns; and although this does not guarantee their correct application in our projects, it provides enough food for thought, and makes the chances of using this tool in the right way as large as possible.

QUOTE
Excessive number of constructor parameters ( Constructor Over - injection ) is not a problem of managing dependencies in general, and passing dependencies through the constructor ( Constructor Injection ), in particular. Rather, it is an indicator that the class in question has too many responsibilities. This smell ( code smell ) comes from the class, and not from passing dependencies through the constructor; and we, as usual, should use it as an incentive to improve our code.

If you look at different DI containers, you can notice that the same concepts are called differently in many places. Any container supports a certain set of strategies for managing lifetime dependency (lifetime management), and although many of them are similar very often they are called differently.

In this regard, the book solves two additional tasks. Firstly, the author introduces consistent terminology (Auto Wiring, Composition Root, Bastard Injection etc), and secondly, gives knowledge of the basic principles that can be used with or without any container. This knowledge can be easily reused , which will save time on learning new libraries, as well as allow you to see the whole picture of dependency management.

QUOTE
Adding Stitches to the application requires additional efforts, so adding them is only necessary.
(Mark on the allocation of interfaces and the creation of additional seams of the application)

This book has one drawback - this is the last fourth part, devoted to the description of six DI-containers. I got the impression that the author considered that the book of 350 pages does not look solid, or the main KPI for him was just the number of pages.

In any case, the efficiency of the last 200 pages is extremely small. The first problem is that each container is a serious enough monster, and it cannot be described on 50 pages. Secondly, the author made a reasonable attempt to unify the description of each container, which led to a large number of “copy-paste” (up to the same paragraphs), and the lack of a description of the unique capabilities of the containers.
As a result, 200 pages were practically wasted, because the current description is enough only to compare the most key points, but they are not enough even to choose a container for your project, not to mention their full use.

To summarize , I want to say that “Dependency Injection in .NET”is the most comprehensive and consistent source of dependency management information. I would recommend the first 3 parts of this book for reading to all teams that use DI containers in their projects.

Rating : 5+ (for parts 1-3) and 2 (for part 4).