Reputation: 8506
I'm developing a solution involving multiple .NET rich clients, a central server and a database containing configuration settings. I want to follow a properly decoupled architecture and not treat application settings like global variables. Instead I want to simply use Dependency Injection to pass the retrieved configuration values to constructors upon app startup as the object graph is built.
This seems straight-forward and simple... except when dealing with changes to settings at run-time. I have noticed that modern applications typically do not require a restart in order for changes to take effect. This is not only a nice convenience for the user, but may be downright necessary when it comes to multiple clients and services that depend on these settings.
I cannot understand how these two ideals (settings injected at startup, and seamless run-time setting value updates) can be achieved. In other words, the only way I can imagine all clients using the up-to-date settings is for all settings-dependent classes relying on some kind of IAppConfiguration service that always queries for the latest value upon each request. Not only does this seem to promote a poor architecture (as per this answer), but it would degrade performance (e.g. if a database query were involved).
Thanks
Upvotes: 2
Views: 59