Topic: About "naive" DI and about architectural powerlessness
About "naive" DI and about architectural powerlessness Never I had desires on subject DI since in all projects where it was found out to use passionate desire of the author DI and over which I had to work, usage DI looked as an abundantly clear antipattern and to me it was always absolutely not clear for what the author wastes time also forces receiving of nothing in exchange? Actually the situation typical enough - me that "experience ", and youth diligently "types cones", but thus, I for some reason to unwinding did not find any distinct explanation from popular writers DI of why naive usage DI will be failure. Therefore I decided to formulate the variant we Look at a common example naive DI: public class HomeController: Controller public HomeController (IBoringItemDataReader, IBoringItemDataWriter, BoringItemChildDataReader, IBoringItemChildDataWriter, IAppDataJsonConverter...) Exaggerating it would be possible to add still IJsonConverter that the converting mechanism json could be changed and that be like IDateTimeProvider, operation with date and time hardly exchanges, but just in case it is necessary "to reduce dependences". We look at implementation IBoringItemDataReader: public class BoringItemDataReader: IBoringItemDataReader and from tens abundantly clear stateless type methods: GetBoringItemById GetBoringItemByNumber GetBoringItemByDataInterval... Children... Whether here these low-level "entrails" it that "service"? Here these all "interiors outside" is encapsulation and architecture? How it turned out, what attempt to "observe" principle DIP obviously causes violation of all remaining principles SOLID and on it close eyes? How it is possible to implement "dependence of service" in a situation when the developer is not capable to create implemented service? The problem here basic - the developer has no skills of creation of the objective decomposition and tries to compensate it usage of the difficult mechanisms, which sense it does not understand. Personally for me DI initially was only the convenient mechanism of creation " architecture". The part of acquaintances assured that DI vital for testing, but here the situation became absolutely absurd, since the architectural decision (to use DI) like as was accepted, but no tests thus existing and in the future they never appeared. Somehow so... principal initial problem DI - inability of developers to create the objective decomposition. It conducts to creation of absolutely wrong, very low-level and fragile system of dependences breaking 4 of 5 principles SOLID. An example of how some try to treat tonsils through back pass. By the way a quite good title for an antipattern - Colonoscopy Injection and for all brotherhood templates of "naive architects" - the arhitekt-proctologist. Update: arguing suggested an idea that actually naive DI breaks principle DIP first of all. Since statement DIP states: Units of top levels should not depend on units of lower layers. Both types of units should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions. abundantly clear that naive service stuck together of methods DAL, at all is not "abstraction". It extreme specific with extreme specific entity types even if structure of these types , and the data is copied with the help (such a cargo-cult ""). here absolutely accurately defined problems - interfaces of top levels start to define low-level interfaces DAL. Separated methods do not cease to be methods of that them cause through the interface.