Home/ Questions/Q 7686109
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-31T19:24:17+00:00

I’m developing a Class Library / API and I need to store some global

  • 0

I’m developing a Class Library / API and I need to store some global parameters that will be used by some classes. I thought about two main ways to do so (ignoring configuration files which I’d prefer not using in this case):

1) Specifying the parameters in a static class, like this:

// 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 pass it to the classes, like this:

// 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 feels more natural for me, but I can think of some possible downsides (if the config is set in two places with different values, for example).

I want to know the possible downsides of each implementation and what is the most common way to do this in known projects of this nature.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’d say #1 is the most common. I know you said that you didn’t 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 taken. You don’t see instances of app.config settings being passed around to every method/function that needs to read a setting. I normally do VB.NET, for which there is a static My.Settings class that basically achieves the same thing as your #1.

    The biggest disadvantage I see to #2 (and probably why it is less common) is that the config class can get passed around a lot. If only a small number of methods actually need to read the config it might be ok, but if many methods need to read the config it starts to become a headache. In my opinion it also clutters up the method signatures. Imagine a class deep in the library that needs to read the config; you may have to pass the config through several higher level classes just to pass it through to the class that needs it.

    I’d recommend at least considering using app.config or web.config as either one of these already have built in functionality for this type of thing.

    EDIT

    I was waiting for Brannon to respond with an example, but since he hasn’t I’ll go ahead and chime in. IOC containers are great tools to help with dependency injection, but I wouldn’t dream of introducing one just for a settings class. If you were already using one, that might be a different story. Lets suppose that you were already using an IOC container and wanted to use it for your config class. That means you still have method signatures that look like:

    Function Add (FirstNumber, SecondNumber, Config)

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

    To be honest some of it comes 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 frequently frowned upon and rightfully so in many cases, but I think that settings/config classes are exceptions to the rule.

    • 0