Dependency Injection

In this episode, Robert is joined by Miguel Castro, who explains dependency injection, which makes it easy to resolve classes at any level in any size object hierarchy, all the while making your application much easier to test. Miguel demystifies this important technique and explains why and how you should use it in every project.

[@pedro.raimundo]

Great video, thanks for putting it together. Just a few constructive feedbacks: 1- Always show the code when explaining/discussing it (perhaps using highlights to help the viewers) 2- In my opinion, the host walks in more than would be desirable. Thanks, and keep up the good work!

[@sahawndada]

I think this is Great feedback and I strongly agree

[@Phcodesign]

The same impression here. But I managed to find a workaround - open another yt window and pause it on screen that previoulsy was showing the code :D.

[@mso-dlx]

@@Phcodesign Yep, good workaround to make up for the deficient presentation with two persons talking about code you don't see otherwise.

[@cycostallion]

Surely demystifies DI. Excellent explanation by Miguel. Thank you.

[@Cmppayne26542]

I think the biggest problem when it comes to learning dependency injection is that the vast majority of the videos will talk nearly the entire length of the video of why you should use dependency injection. Unfortunately they really should be focusing more on how to use the container. This is why it took me a long time to really use it. For those trying to learn, I would recommend studying reflection because that’s pretty much how all of the container works.

[@alb12345672]

Reflection is also slow a crap. Everything has a tradeoff. I guess you can throw hardware at it.

[@Qichar]

Exactly. The container part of it is the conceptually more challenging part to understand. That's because unit testing has been around for a while and a lot of people are already passing in dependencies in the constructor or possibly as parameters in specific method calls (via interfaces). This is just good sense when decoupling. What the container part buys you is a way to consolidate dependency resolution without having to hunt through the code everywhere to implement the change whenever you decide to refactor an abstraction or separation of concern (sometimes you want to further sub-divide concerns, for example). I realize there is global replace, but it's still a pain to do and make sure you've gotten them all. Not to mention if you're using source control resolving such a change which hits dozens of files instead of ONE file if you're using a container. @alb12345672 Yes, reflection is slow, but it happens once at startup. The container registers key value pairs (a hash); all it's doing is interpreting the container lamda expressions and figuring out what concrete classes they correspond to, and then entering a string key to go with that value (concrete class). So it's one time at startup in exchange for code maintainability. To be honest, almost all abstractions in code (including calling subroutines!) is a type of this trade-off, which is run-time performance for code maintainability. If you've built a project of any appreciable size with a sizable development team, trust me, it's a trade-off you make gladly.

[@jonathansteele3971]

Yes, understanding the relationship of the container was the "a-ha" moment for me.

[@kevinm8865]

@Chase Payne Amen! It's so irritating trying to learn this modern C# stuff because of all the indirection. The abstractions in my opinion overly complicate the code with lots of pointers to various files and interfaces, and implementations, etc. This, "the vast majority of the videos will talk nearly the entire length of the video of why you should use dependency injection. Unfortunately they really should be focusing more on how to use the container", is spot on. Everyone is evangelizing DI but when I ask how to use, people get quiet. "It just works". Does it?

[@smblog2354]

Can you please suggest some resources to learn more about this, specially the reflection as you mention?

[@martinshields7122]

This is an excellent video highlighting the importance of DI.

[@Omery-od6vu]

Take a snapshot @23:02 near the video to see what they've later discussed

[@amalkrish]

This really did demystify DI for me , thank you so much !!

[@nigelnaicker7948]

i loved this, iv used it for a while but never really understood what i was doing and why, the host was basically me , i loved the raw confusion and interaction he provided, he asked real questions, not rehearsed nonsense. Great job to both guys.

[@sssutube1]

Robert did a good job of asking questions at the right time. And Miguel was very good at explaining too

[@aurinator]

You're absolutely right about Reflection, and incidentally if anyone really is worried that it might actually have a noticeable impact on performance, that's a pretty explicit indication that whatever they're worried might cause it should be broken out, and incidentally exactly this has actually come up before for me professionally with real-time audio compression/decompression and I broke it out into a much lower-level C++ library. This has the added benefit of making everything more SOLID too.

[@rakeshkulkarni2125]

Just beautiful! I really like the way you are teaching, first showing bad code and then fix it, most tutorials just cover how to do it without telling you what’s the problem in the first place.

[@NPC-mj7up]

Great devil's advocate played by the other guy, awesome video.

[@siddheshswa]

This is great. Beautifully explained with example.

[@trongphan6197]

Thanks Robert and Miguel

[@crtune]

I really enjoyed this. You made this all very, very clear. And, I can see the extreme value this has. Couldn't be a better presentation!

[@MicroftHunter]

I'm inspired! Thanks.

[@rahulmathew8713]

Dependency Injection Lay Man Terms. A charging adapter with usb port has inverse dependency with pendrive. Direct dependency means only a pendrive can be plugged into the charging adapter. Usb (universal serial bus technology is called the interface) . The company that made the adapter exposed an interface. Pendrive making company injected the dependency which is the pendrive device. Since the charging adapter has reversed or inversed the dependency you can now plugin a mouse or a keyboard or anything to this adapter. Thats it

[@danpopescu8219]

Excellent explication of the DI. Thank you.

[@lindahem8803]

Oh my god, It just clicked! You guys are awesome!

[@frankbanini8884]

Great point. Loved it. Will take it as my programming principle.

[@anirudha7016]

Love the Explanation. Fantastic examples to help understand DI. This issue of the code not being displayed .. Yeah it bugs but a screenshot to refer to works just fine. Thanks

[@michor10]

Excellent video, guys. Thanks!

[@rishabhkalra9505]

even in 2024, this is such a great explanation about DI in general and how it hooks. The process is still the same (obviously the concept is same as well) but this explanation is on point

[@tajayeb]

Very Good Explanation of a topic i have found very Confusing before now. Good Job

[@Caldaron]

finally a good talk to introduce this...

[@orochinagi1111]

great explanation and very clear!!!

[@tchipilev9]

Hi guys, You've made an awesome presentation. Where can i get the demo code?

[@nexusmeister]

Great video! Helped me a lot to understand that concept

[@alexyang751]

Great video! I was wondering why people could just simply change the constructors by removing/adding interfaces as arguments without changing the instantiation codes that were supposed to be somewhere. So the DI container is doing reflection somewhere in the framework and can examine the constructor arguments and properly create the class instances automatically by traversing the dependency tree when needed.

[@videobatch6vtmtit14]

a very informative video, thank you.

[@ravideshireddy8899]

Nice explanation with code walk through, i like it

[@Max-zp3th]

Great webinar. thank you.

[@shravandurga19]

Best Video on DI

[@AlanCostaPlus]

Robert seems to be a character, his personality just made the presentation. Excellent display by Miguel.

[@PaulOPeezy]

Alan Costa. He sounds like Big Head from Silicon Valley

[@dharmeshsharma]

This is really good but in DI you using two time save method so how to use Unit of Work ?

[@divanvanzyl7545]

Useful knowledge, thanks!

[@thejareddy6368]

What happens when I've two classes one is EmailNotifier and PaperNotifier and both implements INotifier, I tried doing builder.RegisterType().Keyed("EmailNotifier"); builder.RegisterType().Keyed("MailNotifier"); But how to inject which class object to instantiate, Any suggestion would be appreciated.

[@vielassiel9292]

Great video and super helpful.... but for future reference could you please use the dark mode that is built into Visual studio in the first place? You guys implemented for a reason! The super bright white is incredibly harsh on the eyes and makes it VERY difficult to watch at times. ( I know I'm not the only one. )

[@gselby8107]

I am new to DI and I LOVED this video. SO very helpful. I didn't see any links to get the code. Is it still available? Thanks.

[@vamseekrishnam4773]

Guys, this video was amazing. Thanks for that! Could you make a video on Structure Map or point me out to Videos on Structure Map Deep Dive Usage. Thanks in advance :)

[@antevuletic3393]

The code is cool but Miguel is cooler. Would love to have a beer with this man.

[@emmanuelmotsi]

Thanks! Where can we get the code used here?

[@markvanlierop7261]

Instead of the container you could also use a factory and instantiate every object there. Doing it only in one place once too and only calling a specific method to get the desired object just like the resolving example. Is there a reason why using the container (autofac) would be better?

[@shaikzubair4827]

Thanks for good explanation

[@gersonfreiredeamorimfilho3012]

Thanks a lot! It was awesome!

[@deepanshuruhela82]

How to get the code of this video for test on my system, To learn how the DI is work

[@NPC-mj7up]

Interested to see a version of this in .net Core to see if there are many differences using Autofac (I'm guessing not much but would be good to be sure).

[@mohdotnet]

This is a great video, flashbacks of me back in the day when i saw an application with tons and tons of interfaces. and im like hey i remember getting onto a using ado, not IDBContext :P

[@sajadmalik9097]

any other video like this that shows Scoped, transient and scaler... if plx share the link i have been searching the visual studio toolbox but cant find

[@RealDids]

Presentation was a bit too aggressive for my tastes, but other than that, great job on explaining DI/IoC!

[@GruffGuy]

Thx for video. Very useful information for me. Im trying to learn DI and IoC\DI Containters. Can we get any source projects? Will be usefull.

[@EriAirlangga]

There you go github.com/miguelcastro67/DI-Webcast/tree/master/src

[@GubiBF3]

Hi! Is this code anywhere in web? I would love to play with it. Also showing unit testing with DI would be great stuff.

[@danyboucher5320]

Source Code is right here: github.com/miguelcastro67/DI-Webcast

[@ZzBiazZ]

Great video, thank youuuu!

[@_Szakal]

What about Windows Forms? How to access container in not startign form i mean when someXForm is called and contains dependencies since container will be not visible outside Program.cs?

[@98mohammedatifshamim]

can you give me the source code which you showed in the demo

[@expertreviews1112]

Ok so Miguel said he was going to make the code available. Cant find in the description, does anyone know where to find it?

[@danyboucher5320]

Source Code is right here: github.com/miguelcastro67/DI-Webcast

[@MrSegagraff]

Nicee explanation, illustrate the point very well!

[@SClub7Fan]

so it's less about being able to replace the interface class with another functional class of the same interface and more about replacing it with a mockable/testable one? Or would there be complex logic in the container registration to handle passing different implementations of the same interface under different circumstances? It's still not totally clear to me

[@vamseekrishnam4773]

Yes Ethereal. Its about registering "the one specific interface implementing class with that interface" when used as an argument in the constructor of the main class. So, defining the registration would need all 3 pieces so as to help resolve the main class later on * The 3 pieces here being (mainClass, interface, interface implementing class)

[@shahidwani6445]

Is it thread safe

[@sandeshmitake2904]

Nice explanation.

[@WhitbyStuff]

I would have liked an upfront roadmap of where we were going. It would have given a better context when following along. It was always "and now we're here."

[@AltaiiSinan]

You are not showing the code while u are explaining the code at the lines you are talking about in stage 3 :(

[@alirezaghanbarzadeh1679]

In a .Net Microservice app, How to automatically/Dynamically register any new service in Unity container without writing code to register it manually?

[@stoic2454]

any idea, is this sample pushed to git or not ?

[@rahulmathew8713]

How we can do modularity like in prism in Asp.Net, instead of registering every interface in the same function in global. asax

[@agli2076]

Where do i find the source code?

[@amaterasu48]

Whoa show me the code when he is explaining the DI! WTF?

[@MrMoffettbrandon]

Great video

[@nikaburu]

Saying that it's all right to put container instance to static field can be damaging without further explanation. Otherwise ppl can use it as service locator without actual Dependency Injection. Application level container is stored in static field because it must be live for a lifetime of application (and static field is an easiest option). You should use it only within composition root (usually application startup code). Basically: a) never make this field public and b) make sure nothing in you business logic code has autofac as a dependency (check using directives and references if code in a separate project from composition root).

[@Dahgne]

Very enjoyable

[@pearlpappa]

The code can be found in github. github.com/miguelcastro67/DI-Webcast

[@chadsmith7412]

Not all heroes were capes. Thanks for the link!

[@sharansrivatsa210]

Those who are looking for the code: github.com/miguelcastro67/DI-Webcast/tree/master/src Here it is

[@fishboy91]

Maybe it is just me but a lot of these techniques solve problems, I never considered a problem.

[@eldorado6883]

What's the container you used here?

[@whatsupbudbud]

Autofac.

[@saeedatenzi]

Autofac

[@berkayyerdelen927]

WORTH!

[@natepepin09]

Ah, that answers a lot of question.

[@rupeshsinghindia]

show the code when you talk about it

[@fiddler-dv4or]

show the code!!!! please.

[@davidlira8853]

33:05 gold

[@ramganapathy3298]

Where is the source code?

[@WhitbyStuff]

You need to look at the code you're talking about.

[@user-xg7hi5mh3g]

Where we did the DI Container in the desktop application i didbt got it well in the famous.... wht could someone tell me where he did say?

[@MarkGriep1]

Source code seems to be here github.com/miguelcastro67/DI-Webcast

[@dingusagar]

Checkout this simple java example that explains Dependency Injection using a simple Car and Engine analogy. github.com/dingusagar/DependencyInjectionExample

[@winterfrost5253]

Hmmmm... I think the Dependency Injection from ASP.NET Core is way more sophisticated and flexible instead of this.

[@jamesallen74]

Miguel is awesome. The host kinda got in the way too much.

[@hilllasten7059]

actually

[@charg1nmalaz0r51]

problem with programming from a complete beginner trying to learn on their own is that the only people putting out content tend to be lazy programmers or older programmers who dumb stuff down so much or use outdated techniques that it creates a new bunch of people using those techniques and the cycle keeps going on and on. Thats why you keep having to repeat yourself. Like peopel always bang on about inheritance being a minefield waiting to blow up in your face yet everyone teaching coding uses it as the main go to technique

[@zahirjacobs716]

That cap though...

[@samsungsamsung-hd3bj]

Y u no share source code? Bad Microsoft, not cool

[@gregc6107]

IT IS NOT TRUE, that you don't need IOC if you don't do unit testing. IOC is great when you want to do design patterns or change a class out based off the environment your own. Maybe in production we want to use a real EmailSystem but in test an locally we want to write out to a log. STOP SAYING UNIT TESTS IS THE ONLY REASON FOR IOC. That is all

[@bonzo6989]

No code while explaining? Come on guys!

[@sf2998]

😆

[@yagedygag]

anybody else wonder why the guy on the right wears two watches

[@GH-yk6zd]

@3:03 turns out: new people are entering the space all the time. this is a major problem in software development. 99% of people who are teaching you disregard the fact that you do not have the same experience.

[@felipecerdasaavedra2853]

Great video but it is way too long. I think you should split it in parts no longer than 10 minutes.

[@brahmcdude685]

this example is way way way too complicated. how about just ONE dependency for starts?

[@ColoradoCarGuy]

Lost interest when they started standing in front of the screen talking to each other and forgetting who their real audience really is.

[@j7048]

This video just auto-played, because I was doing something else, I just let it play, but the part you referenced was rather annoying. He asked like 15 questions and the other guy cut him off on everyone of them, only 2 words into the question. It was too annoying, so I turned it off.

[@LukeAvedon]

I am dumb.

[@Coolskhan]

from 23:00 till 29:21 the viewer is out of context.

[@kenmurray4005]

The aim is good and the objective is simple, but the code is a none maintainable mess.

[@bartholomewtott3812]

Giving up object construction to a framework implies a simplistic construction model which implies that OO is probably not the right paradigm for what ypu're doing.