The most standard way to set configuration parameters in a class library

Question

I am developing a class library / API, and I need to save some global parameters that some classes will use. I thought of two main ways to do this (ignoring the configuration files that I would prefer not to use in this case):

1) Setting parameters in a static class, for example:

// Stores and validates settings ApiConfiguration.SetConfiguration("some values or class here"); var methods1 = new MyFirstApiMethods(); methods1.DoStuff(); // Internally uses static ApiConfiguration. var methods2 = new MySecondApiMethods(); methods2.DoOtherStuff(); // Internally uses static ApiConfiguration. 

2) Creating an instance of the configuration class and passing it to classes, for example:

 // Create an instance of the configuration class var config = new ApiConfiguration(); config.ServerName = "some-server-name"; var methods1 = new MyFirstApiMethods(config); methods1.DoStuff(); // Uses the supplied ApiConfiguration instance. var methods2 = new MySecondApiMethods(config); methods2.DoOtherStuff(); // Uses the supplied ApiConfiguration instance. 

The fist option seems more natural to me, but I can think of some possible minuses (if, for example, config is installed in two places with different values).

I want to know the possible disadvantages of each implementation and the most common way to do this in well-known projects of this kind.

Answer 1

I would say that No. 1 is the most common. I know that you said that you do not want to use configuration files, but if you look at how .NET uses app.config, I think you will see that a similar approach to # 1 is accepted. You do not see instances of the app.config parameters passed to each method / function that the settings should read. I usually do VB.NET for which there is a static class My.Settings, which basically achieves the same as your # 1.

The biggest drawback that I see in # 2 (and probably why it is less common) is that the configuration class can be passed for many reasons. If only a small number of methods actually need to read the configuration, this can be normal, but if many methods need to read the configuration, it starts to become a headache. In my opinion, this also clutters the method signatures. Imagine a class in a library that a config should read; you may need to pass the configuration through several classes of a higher level in order to pass it to the class that it needs.

I would recommend at least consider using app.config or web.config, because either they already have built-in functions for this type of thing.

EDIT

I was waiting for Brannon to respond with an example, but since he doesn’t, I will go ahead and call you back. IOC containers are great tools to help with dependency injection, but I would not dream of one thing for the settings class. If you have already used one, this may be a different story. Suppose you already used an IOC container and wanted to use it for your configuration class. This means that you still have method signatures that look like this:

 Function Add (FirstNumber, SecondNumber, Config) 

Admittedly, this example is stretched, but you get the idea. The IOC container will resolve your Config dependency (it will create a configuration class for you), but you still have a config as a parameter for each method / constructor that it needs.

Honestly, some of them come down to personal preference. Keep in mind that VS / .NET uses # 1 out of the box when you use app.config. I know that static classes are often mistrustful and true in many cases, but I believe that the / config settings classes are exceptions to the rule.