|
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?
|
|
|
|
|
This month is my 40th anniversary developing frameworks--the term didn't even exist back then--so IoC happens naturally. But there's already enough boilerplate without this DI rubbish.  I suppose I'd use it if the value was obvious in some situation, but so far I haven't felt compelled--or maybe have done it without realizing! I don't ascribe much value to unit tests, greatly preferring integration and regression tests, so DI does nothing for me on that front. Frameworks have to be tested using serious applications; anything less just scratches the surface and proves little.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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! 
|
|
|
|
|
Haha. Wag the dog.
"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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
I wrote my reply (The Lounge[^]) before I read yours, but I see we got to the same place on DI. Very interesting. Great post.
|
|
|
|
|
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! 
And so it is in the IT / Development Community.
|
|
|
|
|
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
|
|
|
|
|
|
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.”
|
|
|
|
|
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.
|
|
|
|
|
I'm leaving within the hour for a weeklong trip to Marathon, FL for a much needed vacation. Of course the laptop is going with me just in case something needs fixing. Hopefully I won't have to use it too much! 
So long suckers!
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
kmoorevs wrote: Of course the laptop is going with me just in case something needs fixing
That's not a vacation.
Leave it at home. Disable all work related devices (and/or work related notifications)
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Enjoy - and take the battery out and leave it at home ... 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
If you have MS Teams on your phone just remember to disable it so you don't get notifications over both mobile data & Wi-Fi
|
|
|
|
|
|
Dear Boss,
I'm leaving for Florida on <day> for a vacation and I will be gone for <days>.
I'm leaving all digital devices at home and cannot be reached for <days>.
This is my vacation, I have earned it and I plan on enjoying it by unplugging.
Thanks for your understanding, or not!
Your loyal employee
The most expensive tool is a cheap tool. Gareth Branwyn
JaxCoder.com
|
|
|
|
|
I turned last weekend from a 3-day weekend into a 4-day one by taking Friday off as a holiday. It's been years I've done that.
I was rewarded with tornadoes and a power failure that lasted for nearly 48 hours. I'm not sure whether I've jinxed myself, but this would be in line with my typical luck.
OTOH...I'm trying very hard to tell myself I'm lucky I haven't suffered any actual damage, other than one dead PC that (I'm guessing) didn't like the brownouts, even though it was sitting behind a UPS...
|
|
|
|
|
If you’re gone for a week and it all falls apart - ask for a big raise!!
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
Unless it fell apart because of your code.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
