2

I have a 3 tier application setup like so with a console presentation layer. In my business logic I have a class where I declare a number of different variables that are fixed i.e. the values won't change. The values of these variables are taken from app settings.

Now the problem I'm finding is that my class calls off to different methods where these variables are being passed around via the method signatures. Is this good practice? If not, would it not be better using constants instead? If so, where should the constants live so I can access them where ever I need them rather than passing variables around?

EDIT

Adding some code for you guys. So they're global variables I am referring to here.

OK so in my console app (presentation), I currently have something like this:

public class Program
{
    public static void Main(string[] args)
    {
        MainClass myClass = new MainClass(appSetting1, appSetting2, appSetting3);
    }
}

Then in MainClass I have:

public class MainClass
{
    private string _appSetting1 = string.Empty;
    private string _appSetting2 = string.Empty;
    private string _appSetting3 = string.Empty;

    public MainClass(string appSetting1, string appSetting2, string appSetting3)
    {
        _appSetting1 = appSetting1;
        _appSetting2 = appSetting2;
        _appSetting3 = appSetting3;
    }

    public void MyMethod()
    {
        Method2(_appSetting1, _appSetting2);
        Method3(_appSetting2, _appSetting3);
        Method4(_appSetting1, _appSetting3);
    }
}

I hope you can see what I mean. I'm finding myself passing around global variables across multiple methods. I just thought there would be an easier way of doing this? Such as creating a constants class or something on the lines of that? I'm not 100% sure of the best approach to go for.

In my MainClass I could just declare my global variables like this:

    private string _appSetting1 = ConfigurationManager.AppSettings["appsetting1"];
    private string _appSetting2 = ConfigurationManager.AppSettings["appsetting2"];
    private string _appSetting3 = ConfigurationManager.AppSettings["appsetting3"];

But do I really want to be doing that in my business logic?

Ibrar Hussain
  • 1,791
  • 2
  • 15
  • 19

3 Answers3

1

if they are in the app.config and shouldn't change you should always reference them from there rather than passing them as parameters. This way your intention that they are static values is clear in the code.

EDIT

Jims answer makes sense in that case. Its really just a short hand so instead of writing ConfigurationManager.AppSettings["appsetting1"]; you use Settings.AppSetting1. either way you would be repeating yourself if you declare them at the top every class into class level variables. I like Jim's answer better than mine though as you can extend it. I keep all config in the db and then use a singleton which has a proc call in the private instance constructor to load config. Jims answer could implement this later without you needing to change your calling code. Generally config files are a pain.

Jules
  • 1,071
  • 2
  • 18
  • 37
  • Thanks Jules. OK so my only issue with that would be if I needed to use the app settings in different classes. Let's say I have 3 classes that need to use appSetting1, appSetting2 and appSetting3. I would need to globally declare these at the top. Just seems like I'm repeating myself that's all. What do you think? – Ibrar Hussain Apr 16 '13 at 20:56
  • Jims answer makes sense in that case. Its really just a short hand so instead of writing ConfigurationManager.AppSettings["appsetting1"]; you use Seettings.ApSetting1. either way you would be repeating yourself if you declare them at the top every class into class level variables. – Jules Apr 18 '13 at 09:36
1

I am of the config-free mindset.

If these things presumably don't change, then have an assembly that projects can reference that return the values.

I shy away from configuration files. I realise they are needed in deployment circumstances, but given that your requirement, I'd recommend a common class library that everything else can use and reference.

If you do have to change something supposedly constant, you change it in one place.

Moo-Juice
  • 38,257
  • 10
  • 78
  • 128
1

Another possibility is to create a Settings class that loads them and exposes them as public readonly. This has worked well for me in the past:

public class Settings
{
    public static readonly string AppSetting1;
    public static readonly string AppSetting2;
    public static readonly string AppSetting3;

    static Settings()
    {
        AppSetting1 = ConfigurationManager.AppSettings["appsetting1"];
        AppSetting2 = ConfigurationManager.AppSettings["appsetting2"];
        AppSetting3 = ConfigurationManager.AppSettings["appsetting3"];
    }
}

The static constructor is called automatically before the first access to any of the variables, so you don't have to call it explicitly. Your program can access the variables as Settings.AppSetting1, etc.

Jim Mischel
  • 131,090
  • 20
  • 188
  • 351