Dependency Injection To The Core!
There's a new product in town that embraced dependency injection to the core: .Net Core (and, therefore, ASP.Net Core). If you like dependency injection (DI), .Net Core gives you DI overload, like sugar sprinkled on honey with a cherry on top!
There was a time when DI was such a hot topic, everyone just wanted to get in the buzz. Suddenly, passing a parameter was not just passing a parameter anymore. Your practice could actually be DI without you knowing about it. DI was a pattern that solved real problems and it just needed to be recognized. It grew beyond the basics so fast, so much that DI frameworks even started popping up everywhere.
If it's important, you give it a name. Searching for the history of DI, you will find this near the top results: https://yauritux.wordpress.com/2011/04/03/history-of-dependency-injection-di/, which is referred to in a forum. The forum mentions Robert C. Martin as the one who created the concept as the Dependency Inversion Principle. It is generally accepted that the term "Dependency Injection" was first coined by Martin Fowler.
There was a time when so many had to ask how to do it. There was confusion. Do you need a DI framework to get it done right? How about IoC/IoC containers and why they seem to go hand in hand with DI? Is it really that difficult? Or is it so simple it's complicated?
Years since, DI is now just another pattern. Now, it's the go to solution for almost anything, including how to avoid antipatterns. DI is so common, it doesn't seem so special anymore. And that's exactly how it feels like in .Net Core.
Is it good? Is it bad? I don't know really. For now, it looks right. Singleton was an exciting pattern until it was abused and branded an antipattern. Are we seeing a DI abuse happening right in front of us? Even so, is it causing problems? I wonder...
What do you think?
There was a time when DI was such a hot topic, everyone just wanted to get in the buzz. Suddenly, passing a parameter was not just passing a parameter anymore. Your practice could actually be DI without you knowing about it. DI was a pattern that solved real problems and it just needed to be recognized. It grew beyond the basics so fast, so much that DI frameworks even started popping up everywhere.
If it's important, you give it a name. Searching for the history of DI, you will find this near the top results: https://yauritux.wordpress.com/2011/04/03/history-of-dependency-injection-di/, which is referred to in a forum. The forum mentions Robert C. Martin as the one who created the concept as the Dependency Inversion Principle. It is generally accepted that the term "Dependency Injection" was first coined by Martin Fowler.
There was a time when so many had to ask how to do it. There was confusion. Do you need a DI framework to get it done right? How about IoC/IoC containers and why they seem to go hand in hand with DI? Is it really that difficult? Or is it so simple it's complicated?
Years since, DI is now just another pattern. Now, it's the go to solution for almost anything, including how to avoid antipatterns. DI is so common, it doesn't seem so special anymore. And that's exactly how it feels like in .Net Core.
Is it good? Is it bad? I don't know really. For now, it looks right. Singleton was an exciting pattern until it was abused and branded an antipattern. Are we seeing a DI abuse happening right in front of us? Even so, is it causing problems? I wonder...
What do you think?
Comments
Post a Comment