I have a console application that I am rebuilding from C to C#. This application has to be able to support the legacy method of storing information like parameters from a command-line and parameters from a file (called the system parameters) that customize each run. The system parameters file is in plain-text with a simple key-value structure.
My questions are:
- Should I combine these different parameters into a single Configuration object?
- How would I call this configuration object from the code to store parameters?
- How would I call this configuration object from the code to retrieve parameters?
- Should this object be strongly-typed?
- I will need access to this structure from a lot of different places in the code. What is the most elegant way to retrieve the values in the object without passing the object itself around everywhere?
I have a feeling that it should be a single, strongly-typed object and that it should be an instantiated object that is retrieved from a repository with a static retrieval method however I really want validation of this method.
I like using
Settings. These can be generated automatically either by creating a settings file using the Add New File dialog box, or by adding a default settings file from project properties.Each setting may be in user or application scope, which controls whether or not the user can change them or they are restricted to their default values. They are easily saved with the
Save()method and loaded automatically into the staticDefaultproperty.Yes. If you have both user/application based settings and per-run settings you should use two different classes – the normal (saved) settings and the per-run settings.
As long as you don’t save the per-run settings, you should be safe and settings are still quite easy to use. These are static settings though. If the same application run needs several instances – this is the wrong approach.