3 ms·

I am aware of this, but like many other, I find the IOptions<T> a bad abstraction. This blog has similar thoughts: https://rimdev.io/strongly-typed-configura

I am aware of this, but like many other, I find the IOptions<T> a bad abstraction. This blog has similar thoughts: https://rimdev.io/strongly-typed-configuration-settings-in-asp-net-core-part-ii/ https://rimdev.io/strongly-typed-configuration-settings-in-a... or this blog: https://adamstorr.azurewebsites.net/blog/beyond-basics-aspnetcore-adding-and-using-configuration https://adamstorr.azurewebsites.net/blog/beyond-basics-aspne... Or simply google 'asp net strongly typed configuration' and notice everyone seems to be reaching similar conclusions and building their own things. Just load the setting yourself and register it as a singleton.

macca321 6y ago
I don't like it either, but one advantage is that the settings can be live updated when the config files change
oaiey 6y ago
Do not use Options. Use regular poco bound against Configuration sections like the rest of us :)
nullsense 6y ago
The interface just doesn't bother me. I make reasonably good use of the hierarchical config providers including some custom ones. Plus it supports actually being able to live update the config values. Meh, seems like just an interface to me.
davidfowl 6y ago
Options are a very misunderstood abstraction that we have done a poor job explaining. Those blog posts are simplistic and don't explain what you gain and lose by using the options abstraction.
- zvrba 6y ago
  > that we have done a poor job explaining Yes, indeed you have. I've tried to both skim and read the "introductory" documentation for `Options<T>` and the only gain I could figure out is monitoring + refresh. I still have no idea how to use it though, so I don't.