Timeline for Dependency Injection vs Singleton Pattern
Current License: CC BY-SA 4.0
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S Apr 14, 2021 at 19:27 | history | edited | lennon310 | CC BY-SA 4.0 |
fixed typo
|
| S Apr 14, 2021 at 19:27 | history | suggested | Alexander Stohr | CC BY-SA 4.0 |
fixed typo
|
| Apr 14, 2021 at 16:12 | review | Suggested edits | |||
| S Apr 14, 2021 at 19:27 | |||||
| Oct 13, 2020 at 14:59 | comment | added | scenia | @Theraot thank you very much, I think I got it now. If I understand it correctly, I initialize the container in main then let it handle all the instantiations as needed, so nothing actually needs a reference to the container because the container has references to everything it needs to instantiate. | |
| Oct 13, 2020 at 13:05 | comment | added | Theraot | Dependency injection, does not imply inversion of control containers. Yes, those containers are, at least usually, singleton. I would be against injecting the container, inject factories instead. The containers have a place. If you are doing a library, avoid them, you would lock the consumer of the library, but for an application they are ok (I would then suggest to make the app as thin as possible, dealing only with external systems, and have the core be a library). How would you do dependency injection without a container? You do it injecting from main (or a other composition root). @scenia | |
| Oct 13, 2020 at 8:09 | comment | added | scenia | @Theraot just to clarify, isn't the container essentially a public singleton and thus global? I'm really confused because it feels like all the DI container really does is bundle all the global singletons into one global singleton. How else would I access it? If I inject it into everything, the entire advantage of having a container goes away. | |
| Jul 10, 2019 at 15:05 | comment | added | k3b | In my opinion the main reason to favor DI over Singleton-pattern is that it is impossible to mock out the singleton in automated tests. If you dont do test-automatisation and have only one implementaion SP is easier/cheaper than DI | |
| Jul 10, 2019 at 3:12 | vote | accept | Bastien Vandamme | ||
| Jul 9, 2019 at 18:16 | comment | added | John Wu | It's worth noting that a "singleton" type resource might need different handling in different applications, e.g. in a desktop application a true singleton would be suitable for user context data but in a web application that would be disastrous. That's one of the reasons the composition root is kept separate. | |
| Jul 9, 2019 at 15:11 | answer | added | JonasH | timeline score: 6 | |
| Jul 1, 2019 at 4:38 | comment | added | Theraot |
Note: when I say "you control", I mean something you can create custom instances of it. Not necesarily something of which you control the implementation. Edit: for example I can have javascript functions that take a node instead of asking document, and you can see how that leads to solutions such as dependency injection. And yes, I could still write code that access document, at that point it is about being vigilant (and perhaps have tools check). At the end it is self imposed rules. They had to have a positive tradeoff... I will not ask for inversion of control for a few lines of code.
|
|
| Jul 1, 2019 at 4:29 | comment | added | Theraot | That is a good example. Yes you need it, and on the other hand you are better of isolating from it. Wrap it in something you can pass around or inject, that way you can run tests agasint your code under different configurations. Notice that, although I said that public singletons are bad, I am not saying that you should eliminate them or avoid them. That would be like asking for a C program to not use standard input and output, or javascript code to never access the DOM. I'm not that purist. Some part of you code deals with that kind of things, and abstract them to terms you control. | |
| Jul 1, 2019 at 4:12 | comment | added | Bastien Vandamme | Is everything coming from your web.config file also wrong then? This config file is also kind of global variable. We should not use it? | |
| Jul 1, 2019 at 4:09 | comment | added | Theraot | I have no solution for you, just this: public singletons are bad, they are effectively globals. Dependency injection is is good, for instance it makes testing easier, but is not the only alternative. Similarly there are alternatives to containers, but depending what you are doing, you might want them. In fact, you might want to inject sigletons! (not public and with strong concurrency guarantees, but singletons). So, no, having singletons is not the problem, it is how you use them. I suspect the same is true for the DI container. We can keep wishing for a pattern that prevents being abused. | |
| Jul 1, 2019 at 2:37 | comment | added | Bastien Vandamme | Yes. This is my secret argument. What is the real benefit of DI when to perform you must use container that, in fact, adding another dependency. What is the point to do DI to avoir dependency by adding a new one from you libraries. So what should I think about all these peopl telling me un must use DI end always avoir singleton? | |
| Jun 30, 2019 at 4:20 | review | Close votes | |||
| Jul 11, 2019 at 3:05 | |||||
| Jun 30, 2019 at 3:45 | answer | added | jdewerth | timeline score: 3 | |
| Jun 30, 2019 at 3:42 | answer | added | candied_orange | timeline score: 7 | |
| Jun 30, 2019 at 1:42 | comment | added | Theraot | You can use one, the other, or both combined. No surprise there. I will remind you that using a library is adding a dependency. We got to decide if we are going to treat it like an external system or not. I do not know how people would usually justify it. However, I guess that if you are going to tie your code to a particular library, having a singleton is no big deal. | |
| Jun 30, 2019 at 1:28 | history | asked | Bastien Vandamme | CC BY-SA 4.0 |