5 ms·
> My biggest bugbear is the way you access your config, which is an absolute and utter kafka-esque mess. Because someone at MS was drinking the DI kool-aid you
by GordonS 6y ago
> My biggest bugbear is the way you access your config, which is an absolute and utter kafka-esque mess. Because someone at MS was drinking the DI kool-aid you have to add a minimum of 5 lines of code to any class you want to access config values in
I'm not sure if maybe you're referring to the Options<T> stuff?
The way I do it is pretty simple.
1. Create a POCO that represents your config. You can have properties for bested configs if you want, e.g. SecurityConfig, MessageBusConfig
2. When the app starts, use a ConfigurationBuilder to build an IConfiguration from whatever Co fig sources you want - typically JSON files and env vars
3. Bind the IConfiguration to your POCO
4. Configure both IConfiguration and the POCO as singletons
Now you can inject the POCO config object wherever you want it, or the IConfiguration should you need it. I feel like this is simple, and works well for dev, test and prod.
- Arelius 6y agoFor other people who are curious POCO stands for "Plain Old CLR Object" So I think just a basic uninhereted object.
- goric 6y agoTypically also implies that the object contains no real logic/functionality and is a simple container for storing some values. Something that could be a record type.
- JohnL4 6y agoI think of "plain old" as meaning "not having dependencies on any framework" as opposed to "not inheriting from anything" or "not having logic".
- GordonS 6y agoApologies, I usually remember to expand acronyms!
- nikolay 6y agoPOCO is the POJO of .Net.
- jdking 6y ago+1 This is the approach I use, to register a config interface in the DI, just grab IConfiguration and bind it to a config class. The options stuff is a car crash.
- deleted 6y ago[deleted]
- oaiey 6y agoExactly. [Removed due to bad wording].
- mattmanser 6y agoWell, work on your reading comprehension, I clearly said I ended up doing exactly that. Plenty of other people piping up saying they also find this bad abstraction obnoxious, sorry you can't empathise and understand we all have difference preferences.
- oaiey 6y agoMy apologies for the wording. Was not intended like that.
- starik36 6y agoI think the OP is referring to accessing the config 5 layers down from the controller. I've run into it myself. 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. It just has bad code smell. 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.
- GordonS 6y ago> 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.
- reader_mode 6y agoSmells like you're not doing DI properly :)
- scns 6y agoIs it a bad design, if it could be held wrong?
- reader_mode 6y agoWell 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.
- munchbunny 6y agoYou 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.