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.
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.
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.
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.
@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?
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!
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.
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
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
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
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. )
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
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?
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?
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.
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
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).
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.
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."
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).
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
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)
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 :)
@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.
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
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
Checkout this simple java example that explains Dependency Injection using a simple Car and Engine analogy. github.com/dingusagar/DependencyInjectionExample
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.
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.
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.
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.
Robert did a good job of asking questions at the right time. And Miguel was very good at explaining too
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.
Reflection is also slow a crap. Everything has a tradeoff. I guess you can throw hardware at it.
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.
Yes, understanding the relationship of the container was the "a-ha" moment for me.
@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?
Can you please suggest some resources to learn more about this, specially the reflection as you mention?
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!
I think this is Great feedback and I strongly agree
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.
@@Phcodesign
Yep, good workaround to make up for the deficient presentation with two persons talking about code you don't see otherwise.
Surely demystifies DI. Excellent explanation by Miguel.
Thank you.
Take a snapshot @23:02 near the video to see what they've later discussed
This is an excellent video highlighting the importance of DI.
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.
This really did demystify DI for me , thank you so much !!
Great devil's advocate played by the other guy, awesome video.
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!
Oh my god, It just clicked! You guys are awesome!
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
Very Good Explanation of a topic i have found very Confusing before now. Good Job
Whoa show me the code when he is explaining the DI! WTF?
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
Robert seems to be a character, his personality just made the presentation. Excellent display by Miguel.
Alan Costa. He sounds like Big Head from Silicon Valley
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
This is great. Beautifully explained with example.
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. )
Ok so Miguel said he was going to make the code available. Cant find in the description, does anyone know where to find it?
Source Code is right here: github.com/miguelcastro67/DI-Webcast
The code is cool but Miguel is cooler. Would love to have a beer with this man.
Hi guys, You've made an awesome presentation.
Where can i get the demo code?
In a .Net Microservice app, How to automatically/Dynamically register any new service in Unity container without writing code to register it manually?
Excellent explication of the DI. Thank you.
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
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?
any idea, is this sample pushed to git or not ?
Thanks Robert and Miguel
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?
You are not showing the code while u are explaining the code at the lines you are talking about in stage 3 :(
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.
The code can be found in github.
github.com/miguelcastro67/DI-Webcast
Not all heroes were capes. Thanks for the link!
Hi! Is this code anywhere in web? I would love to play with it. Also showing unit testing with DI would be great stuff.
Source Code is right here: github.com/miguelcastro67/DI-Webcast
Great video! Helped me a lot to understand that concept
finally a good talk to introduce this...
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
This is really good but in DI you using two time save method so how to use Unit of Work ?
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).
Excellent video, guys. Thanks!
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.
Presentation was a bit too aggressive for my tastes, but other than that, great job on explaining DI/IoC!
Great point. Loved it. Will take it as my programming principle.
Nicee explanation, illustrate the point very well!
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.
Great webinar. thank you.
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."
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).
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
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)
a very informative video, thank you.
How we can do modularity like in prism in Asp.Net, instead of registering every interface in the same function in global. asax
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.
There you go github.com/miguelcastro67/DI-Webcast/tree/master/src
How to get the code of this video for test on my system, To learn how the DI is work
Useful knowledge, thanks!
Great video, thank youuuu!
Nice explanation with code walk through, i like it
Thanks! Where can we get the code used here?
Is it thread safe
I'm inspired! Thanks.
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 :)
Thanks a lot! It was awesome!
great explanation and very clear!!!
Best Video on DI
What's the container you used here?
Autofac.
Autofac
can you give me the source code which you showed in the demo
Great video
Maybe it is just me but a lot of these techniques solve problems, I never considered a problem.
Where do i find the source code?
Thanks for good explanation
@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.
Those who are looking for the code: github.com/miguelcastro67/DI-Webcast/tree/master/src
Here it is
Miguel is awesome. The host kinda got in the way too much.
actually
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
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?
show the code when you talk about it
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
Nice explanation.
Checkout this simple java example that explains Dependency Injection using a simple Car and Engine analogy. github.com/dingusagar/DependencyInjectionExample
You need to look at the code you're talking about.
Where is the source code?
Ah, that answers a lot of question.
Very enjoyable
33:05 gold
show the code!!!! please.
😆
Hmmmm... I think the Dependency Injection from ASP.NET Core is way more sophisticated and flexible instead of this.
Great video but it is way too long. I think you should split it in parts no longer than 10 minutes.
Y u no share source code? Bad Microsoft, not cool
No code while explaining? Come on guys!
WORTH!
Source code seems to be here github.com/miguelcastro67/DI-Webcast
this example is way way way too complicated. how about just ONE dependency for starts?
anybody else wonder why the guy on the right wears two watches
That cap though...
from 23:00 till 29:21 the viewer is out of context.
Lost interest when they started standing in front of the screen talking to each other and forgetting who their real audience really is.
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.
The aim is good and the objective is simple, but the code is a none maintainable mess.
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.
I am dumb.