tags:

views:

587

answers:

6

What would be the best way to implement a psuedo-session/local storage class in a console app? Basically, when the app starts I will take in some arguments that I want to make available to every class while the app is running. I was thinking I could just create a static class and init the values when the app starts, but is there a more elegant way?

A: 

If you want to take the command line arguments (or some other super-duper setting) and put them somewhere that your whole app can see, I don't know why you would consider it "inelegant" to put them in a static class when the app starts. That sounds exactly like what you want to do.

mquander
+3  A: 

I typically create a static class called 'ConfigurationCache' (or something of the sort) that can be used to provide application-wide configuration settings.

Keep in mind that you don't want to get too carried away with globals. I seriously recommend taking a look at your design and passing just what you need via method parameters. You're design should be such that each method receives a parameter for what is needed (see Code Complete 2 - Steve McConnell).

This isn't to say a static class is wrong but ask yourself why you need that over passing parameters into your various classes and methods.

j0rd4n
Nothing inherently wrong with static classes or static methods and process-wide data. eg System.Security.Principal.WindowsIdentity.GetCurrent().Name. Identity is an example of process-ambient information, perfect for a static method or class. You wouldn't pass a WindowsIdentity around as a method param, would you?
Cheeso
@Cheeso: Agreed. All I'm saying is that there is an important distinction between data that *should* be process-wide versus data that is made process wide but really shouldn't be.
j0rd4n
+1  A: 

you could use the singleton design pattern if you need an object that you can pass around in your code but imo a static class is fine, too.

iik
+1  A: 

Frankly, I think the most elegant way would be to rethink your design to avoid "global" variables. Classes should be created or receive data they need to be constructed; methods should operate on those data. You violate encapsulation by making global variables that a class or classes need to do their jobs.

JP Alioto
Nothing wrong with static classes or static methods and process-wide data. eg System.Security.Principal.WindowsIdentity.GetCurrent().Name. Identity is an example of process-ambient information, perfect for a static method or class.
Cheeso
A: 

I would suggest possibly implementing a singleton class to manage your psuedo-session data. You'll have the ability to access the data globally while ensuring only one instance of the class exists and remains consistent while shared between your objects.

MSDN implementation of a singleton class

turkeyburger
A: 

Think about your data as a configuration file required by all your classes. The file would be accessible from every class - so there is nothing really wrong with exposing the data through a static class.

But every class would have to know the path to the configuration file and a change of the path would affect many classes. (Of course, the path should better be a constant in only one class referenced by all classes riquiring the path.) So a better solution would be creating a class the encapsulates the access to the configuartion file. Now every class can create an instance of this class and access the configuartion data of the file. Because your data is not backed by a file, you would have to build something like a monostate.

Now you could start thinking about class coupling. Does it matter for you? Are you planning to write unit test and will you have to mock the configuration data? Yes? In this case you should start thinking about using dependency injection and accessing the data only through an interace.

So I suggest using dependency injection using an interface and I would implement the interface with the monostate pattern.

Daniel Brückner
Yup, I am using an IoC conatainer and am doing what you suggest to wrap my App.Config settings already. I guess I should treat the command line args (only two) the same way and just inject them via my IConfigSettings interface into my services. Make sense?