Thanks for your replies. I think I wasn't clear. I *fully* support the use of DI, find it invaluable and also add it if it is missing. What I am talking about is DI Frameworks (IoC containers).
*My comment " I avoid DI like the plague" should have been "I avoid IoC containers like the plague". Sorry for the confusion that caused. * I will *never* hard code construction of a class within another class for all of the reasons others have stated. I find separation of construction of the object graph from it's usage to be one of the primary ways to take advantage of the flexibility OO provides. My question was really about the ASP.NET MVC DI framework. In fact that the example uses DI. So, we all agree with Nick on this one. >> The original example of wrapping up classes into interfaces just to simplify the number of objects being passed in is not something I'd normally do. I also don't do it as I feel parameter hiding increases complexity unless there is a natural class that would emerge from combining the parameters (eg multiple address parameters into one Address class). I was just interested in what is possible using the ASP.NET MVC Framework. So, hopefully that has reduced (rather than added to) the confusion. If anyone knows if this is possible in ASP.NET MVC I would love to hear how it is done. Cheers David On Wed, 4 Dec 2019 at 11:12, Stephen Price <[email protected]> wrote: > I'm with Nick on this one. > > If you have a class that is newing up another class, then you have tightly > coupled classes. Might as well move the second class into the first one, as > you can't have one without the other. If that's how you code, then you > might as well put all of your code into one class. > I think we can all agree that's not the right way to design your code, but > it illustrates my point nicely. > > DI is simply pushing the responsibility for where your class is > instantiated to somewhere other than where you are using it. Pass the > instance in via constructor (or optionally a property) and then (provided > you've specified an interface) then you can pass in a real one or test one > or even a mocked one. No need to go crazy and us an IoC library if you > don't want to (I often don't but MVC core it's built in, so might as well > use it). > > The original example of wrapping up classes into interfaces just to > simplify the number of objects being passed in is not something I'd > normally do. Difficult to understand which leads to hard to maintain code, > even if it does reduce your number of parameters. > It would work, I'm sure, as IoC works out all of the dependencies that are > nested just fine but you are adding a layer of complexity resulting in > things being hidden. Lasagna Code (as opposed to Spaghetti code, layers of > code and you can't find the meat) > > If I come across code not using DI, then I add it. > > cheers > Stephen > > ------------------------------ > *From:* [email protected] <[email protected]> on > behalf of Nick Randolph <[email protected]> > *Sent:* Wednesday, 4 December 2019 7:33 AM > *To:* ozDotNet <[email protected]> > *Subject:* RE: DI in MVC > > > I’m interested in the opinions regarding the use of DI – why is it that > you avoid it? > > > > I’m asking because I see cases where I find DI invaluable (eg testing) and > almost never find that it gets in the way. I’m interested to know whether > the opinions are generated based on bad experiences with DI, or a perceived > lack of benefits of DI. > > > > *Nick Randolph* | *Built to Roam Pty Ltd* | Co-Founder, Technical Lead | > +61 412 413 425 | 1300 613 140 | www.builttoroam.com > The information contained in this email is confidential. If you are not > the intended recipient, you may not disclose or use the information in this > email in any way. Built to Roam Pty Ltd does not guarantee the integrity of > any emails or attached files. The views or opinions expressed are the > author's own and may not reflect the views or opinions of Built to Roam Pty > Ltd. > > > > *From:* [email protected] <[email protected]> *On > Behalf Of *David Burstin > *Sent:* Wednesday, 4 December 2019 10:19 AM > *To:* ozDotNet <[email protected]> > *Subject:* Re: DI in MVC > > > > Yep. I avoid DI like the plague, but no option in a legacy ASP.net MVC > project. Thanks anyway. > > > > On Wed, 4 Dec 2019, 09:58 Greg Keogh, <[email protected]> wrote: > > > > No takers? > > > > Sorry I can't help. I only use DI when I'm forced to, or it's really > simply integrated (like in Blazor). I consider DI another form of "magic > plumbing" and prefer something closer to the service locator pattern. The > problem you're seeing is one I hit when writing Xamarin with FreshMVVM, it > became DI spaghetti --* Greg K* > > > >
