Dependency Injection
HTML-код
- Опубликовано: 12 ноя 2017
- 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.
Наука
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.
Take a snapshot @23:02 near the video to see what they've later discussed
Robert did a good job of asking questions at the right time. And Miguel was very good at explaining too
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.
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.
Surely demystifies DI. Excellent explanation by Miguel.
Thank you.
Great devil's advocate played by the other guy, awesome video.
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 !!
This is an excellent video highlighting the importance of DI.
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?
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!
This is great. Beautifully explained with example.
Excellent video, guys. Thanks!
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
Very Good Explanation of a topic i have found very Confusing before now. Good Job
Oh my god, It just clicked! You guys are awesome!
Great point. Loved it. Will take it as my programming principle.
Excellent explication of the DI. Thank you.
I'm inspired! Thanks.
Thanks Robert and Miguel
Great video! Helped me a lot to understand that concept
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
great explanation and very clear!!!
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
Nice explanation with code walk through, i like it
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
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 :)
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
Useful knowledge, thanks!
Great webinar. thank you.
Hi guys, You've made an awesome presentation.
Where can i get the demo code?
The code is cool but Miguel is cooler. Would love to have a beer with this man.
a very informative video, thank you.
Thanks a lot! It was awesome!
finally a good talk to introduce this...
Nicee explanation, illustrate the point very well!
This is really good but in DI you using two time save method so how to use Unit of Work ?
Great video, thank youuuu!
Best Video on DI
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.
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
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.
Thanks for good explanation
Presentation was a bit too aggressive for my tastes, but other than that, great job on explaining DI/IoC!
Nice explanation.
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
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).
Thanks! Where can we get the code used here?
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
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
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. )
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."
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?
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)
Whoa show me the code when he is explaining the DI! WTF?
Very enjoyable
can you give me the source code which you showed in the demo
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?
any idea, is this sample pushed to git or not ?
Where do i find the source code?
In a .Net Microservice app, How to automatically/Dynamically register any new service in Unity container without writing code to register it manually?
How we can do modularity like in prism in Asp.Net, instead of registering every interface in the same function in global. asax
Is it thread safe
You are not showing the code while u are explaining the code at the lines you are talking about in stage 3 :(
Maybe it is just me but a lot of these techniques solve problems, I never considered a problem.
WORTH!
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).
The code can be found in github.
github.com/miguelcastro67/DI-Webcast
Not all heroes were capes. Thanks for the link!
What's the container you used here?
Autofac.
Autofac
Ah, that answers a lot of question.
Those who are looking for the code: github.com/miguelcastro67/DI-Webcast/tree/master/src
Here it is
show the code when you talk about it
33:05 gold
show the code!!!! please.
Where is the source code?
Checkout this simple java example that explains Dependency Injection using a simple Car and Engine analogy. github.com/dingusagar/DependencyInjectionExample
That cap though...
You need to look at the code you're talking about.
Miguel is awesome. The host kinda got in the way too much.
actually
Source code seems to be here github.com/miguelcastro67/DI-Webcast
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?
😆
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
Hmmmm... I think the Dependency Injection from ASP.NET Core is way more sophisticated and flexible instead of this.
anybody else wonder why the guy on the right wears two watches
No code while explaining? Come on guys!
Y u no share source code? Bad Microsoft, not cool
@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.
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
from 23:00 till 29:21 the viewer is out of context.
Great video but it is way too long. I think you should split it in parts no longer than 10 minutes.
I am dumb.
The aim is good and the objective is simple, but the code is a none maintainable mess.
this example is way way way too complicated. how about just ONE dependency for starts?
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.
this video is the ONLY actual DI video on youtube. the rest are garbage.