This post is intended to set the stage for a later post (though may become a series) I have planned in which I look at using the Bridge design pattern to break the immediate dependency on the Options pattern in a .Net Core application.
The pattern is used to bind configuration settings to an object rather than pollute code with references to the configuration directly. For those not familiar with the pattern, I recommend following the link above.
This topic became of interest to me after reading a couple of Rick Strahl’s blog posts in which he discusses binding configuration settings to objects.
- Strongly Typed Configuration Settings in ASP.NET Core
- Easy Configuration Binding in ASP.NET Core – revisited
In these posts, Rick looks at approaches to binding configuration sections to objects, initially by binding directly to a class and storing that class as a singleton which can then be injected into the controller (or Razor page), and then later comparing that approach to using IOptions<T> or IOptionsSnapshot<T> as advocated by the .Net team.
A comparison between the two is also looked at by Filip W in the post Strongly typed configuration in ASP.NET Core without IOptions.
In both these posts, the authors appreciate the benefits of IOptions allowing the configuration to be changed on-the-fly without having to restart the application (when using IOptionsSnapshot<T>) whereas, an application restart is necessary with a singleton, but are not keen on having to drag along the Microsoft.Extensions.Options package everywhere that the configuration object will be used and having to use IOptions in parameter definitions when what is really of interest is the object T. This is a theme that runs through several blog posts and StackOverflow questions.
Rather than repeat the same discussions here, the links above are provided as background reading to give a foundation for the content I intend to provide in my next post where I will look at creating an intermediary (or bridge) so that projects that have in interest in the configuration object do not have to have a direct dependency on taking an IOptions<T> parameter, but instead take an abstraction representing the configuration.
By bringing an intermediary into the mix, it will also allow for adding functionality such as early validation of the configuration before it is used and decryption of sensitive data.
This will be the focus of the next post.