> To be able to do that, you have to add Options<T> to the constructor of every class in the chain and then configure DI for it.
You really don't - just inject your populated config object where you need it.
Why does something 5 layers down need all the config values?
Not necessarily all options, but just maybe settings for connection to some 3rd party server. You will need the configs.
Re:.NET 5.0
by FroshKiller on Wednesday November 11, 2020 @06:27PM
(#25064262)
Why wouldn't you implement a service for the 3rd party that itself requires the config, then? If a caller of the service needs to know how it's configured for some reason, you should probably be exposing it as a property of the service, not sharing the config directly.
Re:.NET 5.0
by reader_mode on Tuesday November 10, 2020 @08:43PM
(#25054643)
Smells like you're not doing DI properly :)
Is it a bad design, if it could be held wrong?
Re:.NET 5.0
by reader_mode on Wednesday November 11, 2020 @01:09AM
(#25055947)
Well from the sound of it he's instantiating objects manually 5 levels deep and he has control over all those constructors since he passed a new parameter through all of them.
So it sounds like basically he's not using DI (is just using it to pass stuff to controllers) and is surprised that using a library designed around DI is awkward. The correct solution is use DI to construct that hierarchy and then you can just request IOptions at the bottom/where you need it.
Re:.NET 5.0
by munchbunny on Wednesday November 11, 2020 @09:31AM
(#25058684)
You can hold pretty much anything wrong. Sometimes the onus is on the user to understand the tools. Sometimes the onus is on the tools to not be unnecessarily dangerous. DI is a well understood pattern, it just takes some time to wrap your head around it.
“5 layers down”
This is precisely why I jumped ship 5 years ago to Go.
Re:.NET 5.0
by BatteryMountain on Wednesday November 11, 2020 @02:40AM
(#25056310)
Code smell OR a pattern, I believe they call it the "Options Pattern". Obviously not a real pattern like other design patterns.
On my last project, I just assigned the configs to a static class that's available everywhere and the code was just simply much cleaner.