Re: DI in MVC

[David Burstin]

Hi Richard,

Thanks for that - most helpful. Sorry I hadn't replied sooner.

Cheers
David

On Wed, 11 Dec 2019 at 17:35, Richard Carde  wrote:

> On Fri, 29 Nov 2019 at 11:22, David Burstin 
> wrote:
>
>> Hi guys,
>>
>> Got a DI question:
>>
> ...
>
>> Is there a way that I can get MVC DI to resolve IHoldAllInterfaces so
>> that at runtime it will pass in an object that holds all of the internal
>> interfaces already resolved per the startup.cs file?
>>
>
> Sounds like you're after an aggregate service.  I was introduced to AutoFac's
> ability
> 
> to do that a few months ago when doing a code review.
>
> A quick Google suggests Microsoft's built-in DI container won't do it but this
> Stack Overflow thread
> 
> might be of use.
>
>
>> I hope this makes sense - I'm not very good at writing questions clearly
>> *and* concisely :)
>>
>> Cheers
>> David
>>
>
>
> --
> Regards,
>
> RC
>
>
>

Re: DI in MVC

[Richard Carde]

On Fri, 29 Nov 2019 at 11:22, David Burstin  wrote:

> Hi guys,
>
> Got a DI question:
>
...

> Is there a way that I can get MVC DI to resolve IHoldAllInterfaces so that
> at runtime it will pass in an object that holds all of the internal
> interfaces already resolved per the startup.cs file?
>

Sounds like you're after an aggregate service.  I was introduced to AutoFac's
ability

to do that a few months ago when doing a code review.

A quick Google suggests Microsoft's built-in DI container won't do it but this
Stack Overflow thread

might be of use.


> I hope this makes sense - I'm not very good at writing questions clearly
> *and* concisely :)
>
> Cheers
> David
>


--
Regards,

RC

Re: DI in MVC

[Greg Keogh]

I don't know what environments, platforms and coding styles you guys are
using, so it's hard for me to picture how you benefit from DI. I'm mostly
writing WPF, Xamarin Forms, Blazor Wasm and WebAPI at the moment (luckily
no MVC!), and I don't have any problems that DI can solve. I don't have
deep class composition problems or "volatile" dependencies or similar where
DI would help me.

If I start using some DI container, then I'll have to pick one out of the
zoo, learn it, make interfaces and classes, add references, expand
constructors, configure it, etc. I've previously found that debugging
step-into can get lost in the DI code and the IDE has more trouble finding
refences and definitions. Injection code can proliferate and duplicate, I'm
not sure of the lifetime of the dependencies, but worst of all it's all
just more clutter and something I detest … "magic plumbing".

I know some people frown upon this, but I'm quite happy to have a simple
static class in the AppDomain that provides services like logging, http
client, etc which live for the app lifetime anyway. For unit testing I can
just flip a few lines of code.

*GK*

>

Re: DI in MVC

[David Burstin]

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 
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:* ozdotnet-boun...@ozdotnet.com  on
> behalf of Nick Randolph 
> *Sent:* Wednesday, 4 December 2019 7:33 AM
> *To:* ozDotNet 
> *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:* ozdotnet-boun...@ozdotnet.com  *On
> Behalf Of *David Burstin
> *Sent:* Wednesday, 4 December 2019 10:19 AM
> *To:* ozDotNet 
> *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,  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*
>
>
>
>

Re: DI in MVC

[Stephen Price]

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: ozdotnet-boun...@ozdotnet.com  on behalf 
of Nick Randolph 
Sent: Wednesday, 4 December 2019 7:33 AM
To: ozDotNet 
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<https://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: ozdotnet-boun...@ozdotnet.com  On Behalf 
Of David Burstin
Sent: Wednesday, 4 December 2019 10:19 AM
To: ozDotNet 
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, 
mailto:gfke...@gmail.com>> 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

Re: DI in MVC

[DotNet Dude]

Agree with Nick here. Useful for testing mainly and haven’t found it
annoying yet. We don’t bother with tiny apps when writing tests is a waste
of time.

On Wed, 4 Dec 2019 at 10:34, Nick Randolph  wrote:

> 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:* ozdotnet-boun...@ozdotnet.com  *On
> Behalf Of *David Burstin
> *Sent:* Wednesday, 4 December 2019 10:19 AM
> *To:* ozDotNet 
> *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,  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*
>
>
>
>

RE: DI in MVC

[Nick Randolph]

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<https://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: ozdotnet-boun...@ozdotnet.com  On Behalf 
Of David Burstin
Sent: Wednesday, 4 December 2019 10:19 AM
To: ozDotNet 
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, 
mailto:gfke...@gmail.com>> 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

Re: DI in MVC

[David Burstin]

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,  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*
>
>

Re: DI in MVC

[Greg Keogh]

> 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*

Re: DI in MVC

[David Burstin]

No takers?

On Fri, 29 Nov 2019, 12:22 David Burstin,  wrote:

> Hi guys,
>
> Got a DI question:
>
> Say I have a class that has the following constructor:
>
> public MyClass(IAnInterface a, IAnother b, IYetAnother c)...
>
> In my startup.cs I have:
>
> services.AddTransient();
> ...
>
> That all works fine. DI will inject the correct implementations for each
> of the interfaces in the constructors parameters.
>
> BUT, now I want to be clever because the parameter list is growing too big
> (forget SRP, this is a thought experiment). So I create:
>
> public interface IHoldAllInterfaces{
>
> IAnInterface AnInterface {get;}
> ...
>
> }
>
> Now MyClass just takes one parameter, the IHoldAllInterfaces
> implementation, which internally has all of the other interfaces.
>
> Is there a way that I can get MVC DI to resolve IHoldAllInterfaces so that
> at runtime it will pass in an object that holds all of the internal
> interfaces already resolved per the startup.cs file?
>
> I hope this makes sense - I'm not very good at writing questions clearly
> *and* concisely :)
>
> Cheers
> David
>
>
>
>