Dependency Injection mystery, and history...
-
A framework is very different from a library. A library has lots of things that can generally be used on their own, like the C++ STL. A framework is a sketch for how to implement an application. Developers then plug in the pieces that contain the application logic, which the framework glues together. A library will be useful to a broader range of applications, whereas a framework is usually intended for a particular domain.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
Got it. I need to better understand frameworks. Thanx so much.
"A little time, a little trouble, your better day" Badfinger
A library is something you can use. A framework is something that uses you! :(
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
A library is something you can use. A framework is something that uses you! :(
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
DI/IOCs[^] IOC and DI are completely foreign to me. I guess I am too old school. If I interpret these concepts its seems that the libraries are directing the program flow. Sort of like DLL's on steroids. I guess I need to do some more reading. Any suggestions for a newbie to these concepts.
"A little time, a little trouble, your better day" Badfinger
This rather old book introduced me to DI: Dependency Injection in .NET[^]. Even though I don't program in .NET (or C#), I found it very inspirational. It offers a critical stance towards DI (on which I completely agree), while introducing and explaining the concepts.
-
In 2008 or something, Microsoft had some "Enterprise Block" demo or some other codename, for a MEF driven IoC/DI thing for desktop app. I never saw more confusing app. We used the pattern a bit and we got lost and confused in our own small codebase all the time. IoC has continued but has become less confusing I reckon. At my previous work (WebDev) we had simple IoC (MS unity container) with constructor injection (typical .NET Core / MVC stuff). And even my own home made projects, as someone who unapologetically despise IoC/DI, has little bit of it (with my own container thingy, anyway). I can't quite put the finger on it, but IoC/DI as it is used today seems simpler to understand than how it was in those 2008 earlier iterations I think.... To come to my point, the app I am working on at work remind me of those earlier 2008 IoC samples... It's so bloody confusing all the time. I can't quite put my finger on it though. It all seem reasonable in isolation... Not sure what's my point here. What's your thinking on the evolution of IoC/DI in the last 15 years perhaps?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Back in 2010 I started doing WinForms development. I had completely forgotten about it, but now that you mention it, I looked at MEF and MAF at the time and I don't think I understood. I was especially interested in MAF as you could create add-ins for your application. Ultimately, I rolled my own (scan a folder for dll's, read the dll's and look for IMyInterface, instantiate implementing types), which was much easier than MAF and did exactly what we wanted. So anyway, DI isn't much of a thing for WinForms applications, although I'd currently do it by creating instances in the main form and passing them to the other forms, or something like that. Googling for "WinForms dependency injection" now gives some questionable results and they all use different methods. In 2015 I started working for a new employer who did web development. By then I'd read about IoC and DI, even though we didn't use it in WinForms, and this company used it. However, the method they were using was weird, confusing and added no benefit. They had this container which they'd instantiate in each page and/or class and then they did something like
container.GetInstance<ISomething>(). It didn't work so well when the implementation of ISomething needed constructor parameters (which was, of course, a huge hassle and we didn't use the container in many places, instead instantiating directly completely invalidating our method). I think they wrote the container thing themselves, and like many subjects there, they'd read about them, knew they had to do something with it, but they didn't understand it. Then I got assigned to a new project with a coworker from another team and he did understand the concept and he used a third-party DI library in ASP.NET MVC. That's when it really clicked for me as the pros became immediately apparent. Then .NET Core came along and it had built-in DI in ASP.NET. Been using that ever since and it's completely natural for me.Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
In 2008 or something, Microsoft had some "Enterprise Block" demo or some other codename, for a MEF driven IoC/DI thing for desktop app. I never saw more confusing app. We used the pattern a bit and we got lost and confused in our own small codebase all the time. IoC has continued but has become less confusing I reckon. At my previous work (WebDev) we had simple IoC (MS unity container) with constructor injection (typical .NET Core / MVC stuff). And even my own home made projects, as someone who unapologetically despise IoC/DI, has little bit of it (with my own container thingy, anyway). I can't quite put the finger on it, but IoC/DI as it is used today seems simpler to understand than how it was in those 2008 earlier iterations I think.... To come to my point, the app I am working on at work remind me of those earlier 2008 IoC samples... It's so bloody confusing all the time. I can't quite put my finger on it though. It all seem reasonable in isolation... Not sure what's my point here. What's your thinking on the evolution of IoC/DI in the last 15 years perhaps?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I think IoC/DI should all be explained with the simpler statement: "Prefer composition over inheritance." When I began learning OOP all the books, articles & gurus could talk about was Inheritance. It even became one of the 3 Tenets of OOP (PIE - Polymorphism, Inheritance, & Encapsulation). Inheritance was touted like crazy because people though it meant "REUSE!". It caused other problems. So, then we saw a shift to "Prefer composition over inheritance" ala the Gang of 4 Book. Composition simply meant build up a class from other classes. But then, the challenge -- how do those internal classes get configured properly for construction. Then came the DI which is very easy (pass it into the constructor). But then, something happened. People wanted Frameworks to do this whole thing & then came THE GURUS to write books about those frameworks & aaaaaaahhh...... It all became so complicated so you had to buy a $50 book that would explain the framework to you. That's my view of the whole thing. The heart of "Prefer composition over inheritance" is a great principle to follow in some cases which makes for some really nice code. But all the other slopped on top of it, is blech! X| And so it is in the IT / Development Community.
-
The first time I saw DI in action, I was horrified and discouraged. It really broke my heart that that was what modern software had become. In this application, there were controller constructors with upwards of 40 arguments each -- tons of services being injected, many with very similar names (DocumentService, WebDocumentService, ExtendedDocumentService). The problem was very much in how the features were factored into services. But there was also a deeply irrational mania about this -- like people sincerely believed that having tons of services made your project "easy to maintain." So, this really soured my view of DI for a long time. There was a similar craze around interfaces and extracting an interface for every single class. There was a religious belief that this made your code "easy to maintain" because of the "D" in SOLID. ("D"epend on interfaces, not concrete classes.) The thing about this is there is a good case for DI, but you have to strip away the dogma and apply it smartly. And not every class or service needs and interface. Yes, it's a good idea to minimize biz logic in your controllers (for example) to assure testability. And when you get into testing, you'll find that -- yes -- you need to pay attention to what various classes depend on. Interfaces are a miracle when you have truly more than one implementation of a service, but they are just clutter (mental and physical) if you think they belong absolutely everywhere. So, today I see the benefit of DI, but I had to learn it in a cleansheet way and see the benefits on my own. The abusive implementation I had to deal with early on set me back a long time.
-
In 2008 or something, Microsoft had some "Enterprise Block" demo or some other codename, for a MEF driven IoC/DI thing for desktop app. I never saw more confusing app. We used the pattern a bit and we got lost and confused in our own small codebase all the time. IoC has continued but has become less confusing I reckon. At my previous work (WebDev) we had simple IoC (MS unity container) with constructor injection (typical .NET Core / MVC stuff). And even my own home made projects, as someone who unapologetically despise IoC/DI, has little bit of it (with my own container thingy, anyway). I can't quite put the finger on it, but IoC/DI as it is used today seems simpler to understand than how it was in those 2008 earlier iterations I think.... To come to my point, the app I am working on at work remind me of those earlier 2008 IoC samples... It's so bloody confusing all the time. I can't quite put my finger on it though. It all seem reasonable in isolation... Not sure what's my point here. What's your thinking on the evolution of IoC/DI in the last 15 years perhaps?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
The first time I saw DI in action, I was horrified and discouraged. It really broke my heart that that was what modern software had become. In this application, there were controller constructors with upwards of 40 arguments each -- tons of services being injected, many with very similar names (DocumentService, WebDocumentService, ExtendedDocumentService). The problem was very much in how the features were factored into services. But there was also a deeply irrational mania about this -- like people sincerely believed that having tons of services made your project "easy to maintain." So, this really soured my view of DI for a long time. There was a similar craze around interfaces and extracting an interface for every single class. There was a religious belief that this made your code "easy to maintain" because of the "D" in SOLID. ("D"epend on interfaces, not concrete classes.) The thing about this is there is a good case for DI, but you have to strip away the dogma and apply it smartly. And not every class or service needs and interface. Yes, it's a good idea to minimize biz logic in your controllers (for example) to assure testability. And when you get into testing, you'll find that -- yes -- you need to pay attention to what various classes depend on. Interfaces are a miracle when you have truly more than one implementation of a service, but they are just clutter (mental and physical) if you think they belong absolutely everywhere. So, today I see the benefit of DI, but I had to learn it in a cleansheet way and see the benefits on my own. The abusive implementation I had to deal with early on set me back a long time.
-
In 2008 or something, Microsoft had some "Enterprise Block" demo or some other codename, for a MEF driven IoC/DI thing for desktop app. I never saw more confusing app. We used the pattern a bit and we got lost and confused in our own small codebase all the time. IoC has continued but has become less confusing I reckon. At my previous work (WebDev) we had simple IoC (MS unity container) with constructor injection (typical .NET Core / MVC stuff). And even my own home made projects, as someone who unapologetically despise IoC/DI, has little bit of it (with my own container thingy, anyway). I can't quite put the finger on it, but IoC/DI as it is used today seems simpler to understand than how it was in those 2008 earlier iterations I think.... To come to my point, the app I am working on at work remind me of those earlier 2008 IoC samples... It's so bloody confusing all the time. I can't quite put my finger on it though. It all seem reasonable in isolation... Not sure what's my point here. What's your thinking on the evolution of IoC/DI in the last 15 years perhaps?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I was in awe of "DI" until I found having parameterized constructors also was "DI" (which I already used). If I need to get fancy, and don't want to spell it out, I pass a list of object types and cast them on the receiving end. As per the (MS) "sender pattern".
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
In 2008 or something, Microsoft had some "Enterprise Block" demo or some other codename, for a MEF driven IoC/DI thing for desktop app. I never saw more confusing app. We used the pattern a bit and we got lost and confused in our own small codebase all the time. IoC has continued but has become less confusing I reckon. At my previous work (WebDev) we had simple IoC (MS unity container) with constructor injection (typical .NET Core / MVC stuff). And even my own home made projects, as someone who unapologetically despise IoC/DI, has little bit of it (with my own container thingy, anyway). I can't quite put the finger on it, but IoC/DI as it is used today seems simpler to understand than how it was in those 2008 earlier iterations I think.... To come to my point, the app I am working on at work remind me of those earlier 2008 IoC samples... It's so bloody confusing all the time. I can't quite put my finger on it though. It all seem reasonable in isolation... Not sure what's my point here. What's your thinking on the evolution of IoC/DI in the last 15 years perhaps?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
We adapted Castle Windsor IoC back in the day for LOB apps...today with all the madness of framework version & compatibility (just by looking at recent the issues section at github for the same project)..I wonder if it would be a mess to build or compile old code or rewrite or re-port . also now with the DevOps & Cloud Based apps, plus microservices models. ... [API Cross Cutting Concern 23: Inversion of Control (IOC) | Toolbox Tech](https://www.toolbox.com/tech/programming/blogs/api-cross-cutting-concern-23-inversion-of-control-ioc-022819/).......... I think most new people will be using things like [InversifyJS a powerful IoC container for JavaScript apps powered by TypeScript](https://inversify.io/) [A simple introduction to IOC in Typescript with InversifyJS - Tech Imperialist](https://techimperialist.com/nodejs/a-simple-introduction-to-ioc-in-typescript-with-inversifyjs/) ..oof...
Caveat Emptor. "Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
-
In 2008 or something, Microsoft had some "Enterprise Block" demo or some other codename, for a MEF driven IoC/DI thing for desktop app. I never saw more confusing app. We used the pattern a bit and we got lost and confused in our own small codebase all the time. IoC has continued but has become less confusing I reckon. At my previous work (WebDev) we had simple IoC (MS unity container) with constructor injection (typical .NET Core / MVC stuff). And even my own home made projects, as someone who unapologetically despise IoC/DI, has little bit of it (with my own container thingy, anyway). I can't quite put the finger on it, but IoC/DI as it is used today seems simpler to understand than how it was in those 2008 earlier iterations I think.... To come to my point, the app I am working on at work remind me of those earlier 2008 IoC samples... It's so bloody confusing all the time. I can't quite put my finger on it though. It all seem reasonable in isolation... Not sure what's my point here. What's your thinking on the evolution of IoC/DI in the last 15 years perhaps?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
If one understands the *how* and *why* of dependency injection, then no tool or framework is necessary. In the same vein, IMHO, EF is way overcomplicated bloatware compare to a lean data access layer and knowing how to write stored procedures correctly. Microsoft, when it comes to developer tools, has gone from making tools that enhance productivity with elegant simplicity to making tools that decreases, not increases, simplicity and productivity. “The more they overtake the plumbing, the easier it is to stop up the drain.”
-
In 2008 or something, Microsoft had some "Enterprise Block" demo or some other codename, for a MEF driven IoC/DI thing for desktop app. I never saw more confusing app. We used the pattern a bit and we got lost and confused in our own small codebase all the time. IoC has continued but has become less confusing I reckon. At my previous work (WebDev) we had simple IoC (MS unity container) with constructor injection (typical .NET Core / MVC stuff). And even my own home made projects, as someone who unapologetically despise IoC/DI, has little bit of it (with my own container thingy, anyway). I can't quite put the finger on it, but IoC/DI as it is used today seems simpler to understand than how it was in those 2008 earlier iterations I think.... To come to my point, the app I am working on at work remind me of those earlier 2008 IoC samples... It's so bloody confusing all the time. I can't quite put my finger on it though. It all seem reasonable in isolation... Not sure what's my point here. What's your thinking on the evolution of IoC/DI in the last 15 years perhaps?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
There is a lot of angst and wisdom in all of the other replies. My take is that, like many things of late, developers do not use judgement and assume "if a little is good a lot is better" without doing the analysis of what is really needed. I was doing "Dependency Injection" (hate the term, it should actually be "Dependency Abstraction") before the term was ever coined simply because I needed a little bit of it to make certain things more general. As to why it seems simpler these days perhaps it is because the tooling (such as Unity, et al) have made it simpler to use and when you're less concerned about how the gas ignites to drive the piston it is easier to see the utility of the engine. But that simpler tooling comes at a price, namely we don't always know what is going on under the hood, which can be both a good thing and a bad thing depending on what we're doing and the issues being faced.
