1

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.

2

Re: About "naive" DI and about architectural powerlessness

Hello, IQuerist, you wrote: IQ> 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". It still anything. Here when start these dependences to implement through everyones xml configs, here then really reads off scale

3

Re: About "naive" DI and about architectural powerlessness

Hello, IQuerist, you wrote: IQ> 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. Write on Reddit, only hardly in more details. How type the cones, what decomposition correct and what - is not present, with an example. Not is mandatory correct, even  if it will be curve - the better for . Expression Colonoscopy Injection should be carried out in article title, the term at you turned out absolutely lethal. Even if with article disagree, the term goes to the people and DI it will be reliable , there to it and road.

4

Re: About "naive" DI and about architectural powerlessness

So you offer, considering, it is necessary what to test? I while am better than anything DI did not see.

5

Re: About "naive" DI and about architectural powerlessness

Hello, IQuerist, you wrote: IQ> About "naive" DI and about architectural powerlessness IQ> 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? The author yet did not think over the decision, but wants to lower the risks connected to configuring of the program afterwards. Certainly, collecting of dependences in a uniform tree of objects feeblly influences simplicity and clearness of this tree, however at once from what components the program nevertheless allows to see consists and to control a configuration. I assume that implementation of dependences is used so: At program start there is a container, in it all components are registered at once, the container creates a tree of the dependent components, capable to live independently, and completes the operation (dies). Components work further in itself, without suspecting about presence of container any there. IQ> actually a situation  typical enough - me that "experience ", and the 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 And how still to study in programmers? Only to type cones, to analyze the errors, to change. IQ> we look at a common example naive DI: IQ> 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. The developer gets rid sooner or later of these guts outside - at first hides them behind a facade, isolates them, and then still somehow divides - the amount of dependences between components decreases. But it already concerns the mechanism of implementation of dependences a little. IQ> 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. These plug-ins at first it is necessary learns to select from  from an example above. At first the controler types a heap of dependences, is inflated, it becomes then clear that a certain cluster of these dependences in itself is a component, this component separates, and the controler starts to be blown off - now at it all steam of dependences and he is engaged only in in what should be engaged - to control requests and responses. It is process iterated, the main thing it is not necessary to think that the clear architecture should be born at once. The code should be written, and then be read and corrected. Only after a series of editings the distinct circuit of interaction of objects starts to appear. IQ> 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. It is normal development process. Mahlo who is capable to create adequate objective decomposition at once. At first it is written , solving the task, then he brushes the hair to be ready to the subsequent changes in the task decision. On it time is required if to press on colleagues and to demand implementation of new features instead of alteration old  will long live in the program. With experience programmers learn to defend this time for alterations and the code will look better and easier. Why it is named by a configuration problem (implementation of dependences)? A configuration and architecture not same.

6

Re: About "naive" DI and about architectural powerlessness

Hello, Vladek, you wrote: V> Why it is named by a configuration problem (implementation of dependences)? A configuration and architecture not same. In a case with deranged DI it turns out that the configuration replaces architecture.

7

Re: About "naive" DI and about architectural powerlessness

IQ> By the way a quite good title for an antipattern - Colonoscopy Injection and for all brotherhood  templates of "naive architects" - the arhitekt-proctologist. Google transfer absolutely "lethal"...  Injections By the way, give at once Russian ...

8

Re: About "naive" DI and about architectural powerlessness

Hello, IQuerist, you wrote: IQ> Children... Whether here these low-level "entrails" it that "service"? Here these all "interiors outside" is encapsulation and architecture? As it seems to me, this moment - an attempt consequence to stretch "classical" DI on all remaining areas. Classical is which went from heavy products with advanced public API and support of plug-ins from indirect developers. Here there possibility to palm off the necessary services in the code a minimum  - that is necessary. Unfortunately, DI it is in the pure state absolutely unsuitable for usage in a heavy biz-code. There from DI it is required not to throw services and to give object, and a method to drag these services on the long call chain, and the composition of dependences is often in advance unknown and is defined in . For  considered here the Author: LWhisper Date: 30.05 13:51. IQ> 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. Here yes-yes-yes. In practice DI in itself in any way does not help and does not simplify testing process. With semiten dependences it is equally unpleasant to cover complex code with tests that with DI that without. Idle time should not demand DI for tests IQ> Somehow at all so...  principal initial problem DI - inability of developers to create the objective decomposition. +1, only I a little in another way formulated. A phrase "I added possibility" at architecture level actually means "now to all of us it is necessary to use it". In itself DI saves a heap of time, but only till the moment when it does not get out of the native niche. After that it is better to look towards other tools. UPD, P.S. It is not necessary to lean on SOLID as on argument in disputes. It unfortunately perceive as a magic wand though in practice the approach "because SOLID" works not better, than the plane from a cargo cult. Nobody cancelled a head

9

Re: About "naive" DI and about architectural powerlessness

Hello, Glory, you wrote: Hello, IQuerist, you wrote: IQ>> 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. Write on Reddit, only hardly in more details. I to tell the truth not so in course as "to advance idea" in modern IT community How type the cones, what decomposition correct and what - is not present, with an example. Not is mandatory correct, even  if it will be curve - the better for . Cones type very simply when weeks fight with abstractions which itself created and thus they obviously degrade that you would not do and thus also fault to fall down there is nobody About "the correct decomposition"  do not write articles, about it write the thesis for a doctor's degree Expression Colonoscopy Injection it is necessary to carry out in article title, the term at you turned out absolutely lethal. Well with the general help I hope, the antipattern goes to masses. Therefore as a situation with naive DI simply absurd. Even if with article disagree, the term goes to the people and DI it will be reliable , there to it and road. I had no purpose " DI" for " architecture" this fine decision see COM and OLE. Me the unwillingness (simply once again enraged the typical?) separate programmers a few to think that they do.

10

Re: About "naive" DI and about architectural powerlessness

Hello, vsb, you wrote: vsb> So you offer, considering, it is necessary what to test? I while am better than anything DI did not see. I suggest not to make architectural decisions in  on "services" (testing) which probabilities with the highest share will be never implemented.

11

Re: About "naive" DI and about architectural powerlessness

Hello, Vladek, you wrote: V> the Author yet did not think over the decision, but wants to lower the risks connected to configuring of the program afterwards. Certainly, collecting of dependences in a uniform tree of objects feeblly influences simplicity and clearness of this tree, however at once from what components the program nevertheless allows to see consists and to control a configuration. Lowering of risks by means of violation SOLID? V> I assume that implementation of dependences is used so: at program start there is a container, in it all components are registered at once, the container creates a tree of the dependent components, capable to live independently, and completes the operation (dies). Components work further in itself, without suspecting about presence of container any there. All beautifully also is a fine example - COM. But, alas I with confidence can tell that in the majority of projects business simply does not reach selection of components. . Projects often degrade to the highest cost of support and them or freeze or rewrite from zero. And in this case DI (as the approach)  considerably increases complexity of systems at initial level. IQ>> actually a situation  typical enough - me that "experience ", and the 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 V> And how still to study in programmers? Only to type cones, to analyze the errors, to change. In that that and paradox that problems DI for some reason do not analyze. IQ>> we look at a common example naive DI: IQ>> 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. V> the developer gets rid sooner or later of these guts outside - at first hides them behind a facade, isolates them, and then still somehow divides - the amount of dependences between components decreases. But it already concerns the mechanism of implementation of dependences a little. I.e. it is possible... In the ending... The developer corrects defects caused by violation SOLID, provoked by naive usage DI. But here  there is an ontologic rupture - if the developer is capable to understand, what it "naive DI" was an error then why it in such erraticly a type implemented it? I.e. to pass from naive DI to component architecture, from the developer it is required  the extremely serious professional growth, and on it years are necessary. V> these plug-ins at first it is necessary learns to select from  from an example above. At first the controler types a heap of dependences, is inflated, it becomes then clear that a certain cluster of these dependences in itself is a component, this component separates, and the controler starts to be blown off - now at it all steam of dependences and he is engaged only in in what should be engaged - to control requests and responses. V> it is process iterated, the main thing it is not necessary to think that the clear architecture should be born at once. The code should be written, and then be read and corrected. Only after a series of editings the distinct circuit of interaction of objects starts to appear. I understand it therefore even I do not think aside DI at initial stages of the project since except a syntactic overhead projector it does not bring anything. V> why it is named by a configuration problem (implementation of dependences)? A configuration and architecture not same. In an example naive DI which I resulted, "implementation of dependences" dominates over all. And it by the way has the most amusing consequence - business of the logician "is often squeezed out" "naive DI" in client javascript and in stored procedures. The developer already and itself feels that "naive DI" it restricts, but is persistent from it does not refuse.

12

Re: About "naive" DI and about architectural powerlessness

Hello, LaptevVV, you wrote: IQ>> By the way a quite good title for an antipattern - Colonoscopy Injection and for all brotherhood  templates of "naive architects" - the arhitekt-proctologist. LVV> Google transfer absolutely "lethal"... LVV> Kolonoskopija of Injection LVV> LVV> By the way, give at once Russian ... ... We  people leave "Russian " for meetings and analysis of flights

13

Re: About "naive" DI and about architectural powerlessness

Hello, Sinix, you wrote: S> Hello, IQuerist, you wrote: IQ>> Children... Whether here these low-level "entrails" it that "service"? Here these all "interiors outside" is encapsulation and architecture? S> as it seems to me, this moment - an attempt consequence to stretch "classical" DI on all remaining areas. Yes, it also is "naive DI". In the restricted tool see the decision. S> unfortunately, DI it is in the pure state absolutely unsuitable for usage in a heavy biz-code. There from DI it is required not to throw services and to give object, and a method to drag these services on the long call chain, and the composition of dependences is often in advance unknown and is defined in . For  considered here the Author: LWhisper Date: 30.05 13:51. Yes... To drag a context on the long chain business of decisions. Therefore good decomposition there vital. S> UPD, P.S. It is not necessary to lean on SOLID as on argument in disputes. It unfortunately perceive as a magic wand though in practice the approach "because SOLID" works not better, than the plane from a cargo cult. A head nobody cancelled So after all more often usage DI only this most SOLID and explain. A pier we extremely should reduce dependence differently not on SOLID, differently again it turns out . ... Quite good  - implementation Colonoscopy Injection does not influence an amount , it only adds outside subjects

14

Re: About "naive" DI and about architectural powerlessness

Hello, IQuerist, you wrote: vsb>> So you offer, considering, it is necessary what to test? I while am better than anything DI did not see. IQ> I suggest not to make architectural decisions in  on "services" (testing) which probabilities with the highest share will be never implemented. But after all the unit-testing is the standard-de  in modern . To write a software without tests it how to use  for control of versions.

15

Re: About "naive" DI and about architectural powerlessness

Hello, vsb, you wrote: vsb> But after all the unit-testing is the standard-de  in modern . To write a software without tests it how to use  for control of versions. A unit-testing it not the standard, and only the tool. The standard it never becomes, since to it criteria of an estimation are not applicable.

16

Re: About "naive" DI and about architectural powerlessness

Hello, Sinix, you wrote: S> Here yes-yes-yes. In practice DI in itself in any way does not help and does not simplify testing process. With semiten dependences it is equally unpleasant to cover complex code with tests that with DI that without. Idle time should not demand DI for tests at all And how you suggest to palm off moki/fakes without DI? S> +1, only I a little in another way formulated. A phrase "I added possibility" at architecture level actually means "now to all of us it is necessary to use it". In itself DI saves a heap of time, but only till the moment when it does not get out of the native niche. After that it is better to look towards other tools. What is "a native niche" DI? S> UPD, P.S. It is not necessary to lean on SOLID as on argument in disputes. It unfortunately perceive as a magic wand though in practice the approach "because SOLID" works not better, than the plane from a cargo cult. Nobody cancelled a head +100500. , he should be perceived as  more likely, allowing to try to make impression upon opponents.

17

Re: About "naive" DI and about architectural powerlessness

So all the same, what main thought of your post - that thoughtless usage DI - a typical error of the inept architect, or, what the pattern is overestimated?

18

Re: About "naive" DI and about architectural powerlessness

Hello, Lexey, you wrote: S>> Idle time should not demand DI for tests L> at all And how you suggest to palm off moki/fakes without DI? For example as alternative serivce locator. More generally - dynamic scoping.

19

Re: About "naive" DI and about architectural powerlessness

Hello, Evgeny. Panasyuk, you wrote: EP> For example as alternative serivce locator. More generally - dynamic scoping. Service Locator is not alternative, and a variant of implementation DI. Contexts, in general, too.

20

Re: About "naive" DI and about architectural powerlessness

Hello, Lexey, you wrote: EP>> For example as alternative serivce locator. More generally - dynamic scoping. L> Service Locator is not alternative, and a variant of implementation DI. Depends on determination, it is already terminological question. Here for example from wiki: Dependency injection separates the creation of a client's dependencies from the client's behavior, which allows program designs to be loosely coupled [7] and to follow the dependency inversion and single responsibility principles. [4 [8] It directly contrasts with the service locator pattern, which allows clients to know about the system they use to find dependencies. Though on the other hand, hardly more low there: The different injector implementations (factories, service locators, and dependency injection containers) are not that different as far as dependency injection is concerned.

21

Re: About "naive" DI and about architectural powerlessness

Hello, _hum _, you wrote: __> so all the same, what main thought of your post - that thoughtless usage DI - a typical error of the inept architect, or, what the pattern is overestimated? I think a shared problem in other. DI stimulates not skilled developers to fence unreasoned and fragile abstractions at early stages of the project and there where them is not present and cannot be (since first of all they create DAL), breaking principles SOLID. These fragile abstractions start to hinder strongly at creation logic business when forces and enthusiasm will be any more so much. And when also periods start to draw in, business of the logician appears in the most pitiable state. And as validly wrote in :>>> In a case with deranged DI it turns out that the configuration replaces architecture.

22

Re: About "naive" DI and about architectural powerlessness

Hello, IQuerist, you wrote: IQ> Hello, _hum _, you wrote: __>> so all the same, what main thought of your post - that thoughtless usage DI - a typical error of the inept architect, or, what the pattern is overestimated? IQ> I think a shared problem in other. DI stimulates not skilled developers to fence unreasoned and fragile abstractions at early stages of the project and there where them is not present and cannot be (since first of all they create DAL), breaking principles SOLID. These fragile abstractions start to hinder strongly at creation logic business when forces and enthusiasm will be any more so much. And when also periods start to draw in, business of the logician appears in the most pitiable state. IQ> and as validly wrote in :>>>> In a case with deranged DI it turns out that the configuration replaces architecture. And what, in your opinion, then the correct methodology of development - at first not to think about DI, and only on time proprocession when the system finds outlines, already to start to think over, what it is necessary to separate as complete self-sufficient dependences? By the way, in the same wiki are specified  (along with advantages), including about what you speak: Dependency_injection_frameworks

23

Re: About "naive" DI and about architectural powerlessness

Hello, _hum _, you wrote: __> and what, in your opinion, then correct methodology of development - at first not to think about DI, and only on time proprocession when the system finds outlines, already to start to think over, what it is necessary to separate as complete self-sufficient dependences? I think yes, tools and mechanisms should be used as required instead of because so it is fashionable. __> by the way, in the same wiki are specified  (along with advantages), including about what you speak: Dependency_injection_frameworks Imho of the main thing is not written - the maniacal passion to IOC imposed by early implementation DI provokes violation of all principles SOLID.

24

Re: About "naive" DI and about architectural powerlessness

Hello, IQuerist, you wrote: IQ> Hello, _hum _, you wrote: __>> and what, in your opinion, then correct methodology of development - at first not to think about DI, and only on time proprocession when the system finds outlines, already to start to think over, what it is necessary to separate as complete self-sufficient dependences? IQ> I think yes, tools and mechanisms should be used as required instead of because so it is fashionable. So it is true for any case. Why you selected DI? __>> by the way, in the same wiki are specified  (along with advantages), including about what you speak: Dependency_injection_frameworks IQ> Imho of the main thing is not written - the maniacal passion to IOC imposed by early implementation DI provokes violation of all principles SOLID. On what all the same a logical accent - on "maniacal passion to IOC" or on "earlier implementation DI"?

25

Re: About "naive" DI and about architectural powerlessness

Hello, Lexey, you wrote: L> And how you suggest to palm off moki/fakes without DI? In the hard cases - moq/ms fakes/NSubstitute etc. In all remaining to use integration tests easier and more cheaply. The same units-tests, only all infrastructure it is already got and accessible to usage. It though and is a little  at the initial stage, but as a result will not be such that tests green, and here to work - . L> That such "a native niche" DI? I above wrote the Big projects with necessity to support plug-ins from indirect developers. Here there DI works wonders. The most simple example - studio extensions. Compare number of extensions for the code which is cut through MEF (the editor as a matter of fact) and for what normal API only in process (lang services, debugging api etc).