Timeline for Dependency Injection: What are advantages of using a framework? [duplicate]
Current License: CC BY-SA 4.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 17, 2021 at 9:47 | comment | added | Filip Milovanović | "I read that some framework allow things to be "registered" - but that sounds awfully close to a framework that implements the service locator pattern" - Here's the difference. A service locator is a global object that you'd refer to from within a component (such as a class) to obtain a dependency, so there's no explicit parameter for the dependency, and it's not easy to replace it with something else. A dependency injection container configures dependencies and injects them externally, e.g. through constructor injection; you can easily bypass it (e.g. in tests, you can inject manually). | |
| Mar 17, 2021 at 4:33 | history | closed |
Greg Burghardt gnat Doc Brown design-patterns Users with the design-patterns badge or a synonym can single-handedly close design-patterns questions as duplicates and reopen them as needed. |
Duplicate of Dependency injection: should I use a framework? | |
| Mar 16, 2021 at 15:54 | comment | added | Robert Harvey | The Prism Framework (which I use to build WPF applications) does this two ways: by using an IContainer interface, and by employing a Container Locator mechanism. | |
| Mar 16, 2021 at 15:51 | comment | added | Robert Harvey |
The primary objection to the Service Locator pattern seems to be that it tightly binds the container to your code, which can be a problem for many DI containers. See here. The way you solve this is by introducing an Interface or other form of indirection for the DI container; your program then deals with an interface instead of a concrete DI implementation, allowing you to swap the container for any implementation you like.
|
|
| Mar 16, 2021 at 15:39 | comment | added | Robert Harvey | Seeman actually calls it a composition root: see blog.ploeh.dk/2011/07/28/CompositionRoot | |
| Mar 16, 2021 at 15:35 | answer | added | Walfrat | timeline score: 1 | |
| Mar 16, 2021 at 15:23 | comment | added | Robert Harvey | See also stackoverflow.com/q/22795459 | |
| Mar 16, 2021 at 15:21 | comment | added | Robert Harvey | blog.ploeh.dk/2011/08/25/ServiceLocatorrolesvs.mechanics | |
| Mar 16, 2021 at 15:20 | comment | added | Make42 | @RobertHarvey: "Does the terminology really matter all that much?" Yes, otherwise we are not able to communicate as humans ;-). I had enough issues in my job, because we did not realize we talked about different things. "Isn't the real goal determining why any or all of these techniques are useful or not?" ultimately you are right. But if I want to talk with others, we need to speak the same language also. The rest of the things you mentioned sound interesting and I am happy to read more about it if you could provide links. | |
| Mar 16, 2021 at 15:17 | comment | added | Make42 | @Walfrat: I guess both: I am new to the topic, so I am not aware of all those aspects. An explanation of those differences might be helpful. When I wrote up the question I was mostly thinking about the dependency injection which is NOT a service locator pattern. In other words, I was thinking that there are frameworks that help with dependency injection without a registry. It seems to me after reading the thing from Mark Seeman and the other answer that I mentioned that there is indeed no such framework, but the frameworks that are out there are actually what I mean with "service locator". | |
| Mar 16, 2021 at 15:16 | comment | added | Robert Harvey | I don't know. Does the terminology really matter all that much? Isn't the real goal determining why any or all of these techniques are useful or not? Personally, I like the idea of DI containers, especially for complex object graphs, but in practice you're only going to set up those object graphs in an Aggregate Root anyway, so there's always one place where all your configuration goes. The most interesting thing I've seen done with DI containers is "discovery" of modules that can be loaded dynamically at runtime. | |
| Mar 16, 2021 at 15:12 | comment | added | Make42 | @RobertHarvey: It sounds to me that 1) Mark Seeman's "Pure DI"/"Poor man's DI" means my "dependency injection", 2) that his "Explicit register" is the same thing that I called service locator, where you need to explicit register each service - or where you could say that the service gets injected into the framework, and 3) that his "Convention of Configuration" is... well, the non-explicit form of that. Did I get this right? | |
| Mar 16, 2021 at 15:12 | comment | added | Walfrat | Does your question only aim to DI Containers ? Or eventually broaders framework that can do more than being a DI Containers ? (Ex : Java Spring from which you ca use annotation not only for DI but also to manage transaction automatically, role check, url endpoint declaration with automatic parsing of the input request into object...) | |
| Mar 16, 2021 at 15:05 | comment | added | Make42 | @MikeRobinson: Are you sure you mean the same thing as I do, when I say "dependency injection" and that you do not mean the thing that I call "service locator"? | |
| Mar 16, 2021 at 15:02 | comment | added | Mike Robinson | I strongly dislike "dependency injection" because I find that it makes it much more difficult to be certain what the source-code will actually do when executed. But maybe that's just me. | |
| Mar 16, 2021 at 14:57 | review | Close votes | |||
| Mar 17, 2021 at 4:36 | |||||
| Mar 16, 2021 at 14:41 | comment | added | Robert Harvey | Mark Seeman, widely regarded as an expert on DI Containers, provide a pretty good summary of the pros and cons here. | |
| Mar 16, 2021 at 14:30 | history | asked | Make42 | CC BY-SA 4.0 |