views:

296

answers:

4

I'm fairly new to .Net... I have several queries which will execute when the application loads. I want these queries to store the data in an object (a dataset?) which is accessible throughout the application. Should I be using a singleton class? How can a User Control within my application reference public variables in the main application code?

I guess I haven't found a good resource on how / where to store application variables and how to reference them when I need to populate a ListBox, DataGridView, etc.

As a background I'm most familiar with developing using Flex Builder 3, sorry for the vague question... I'm having a problem locating a good reference on the topic (not just populating a Control, but storing the data at an application level and referencing it from anywhere within the app).

Edit: This is for programming a windows forms application using C#

+2  A: 

Sounds like you're using ASP.NET, in which case Application State (MSDN) will allow you to store and retrieve application-wide data that can be accessed from anywhere in the application.

More here:

How to: Save Values in Application State

How to: Read Values from Application State

If you're writing a desktop app, you should create a static class that contains your application wide data, e.g:

public static class ApplicationSettings
{
    public static string InstallDirectory { get { ... } set { ... } };
    public static DataSet SomeDataSet { get { ... } set { ... } };


    static ApplicationSettings()
    {
       // ... initialize or load settings here
    }
}

A singleton isn't necessary here, but if you do require lazy initialization and thread satefy you might want to take that route.

jscharf
Sorry for not clarifying... this is for a windows forms application
Chris Klepeis
+1  A: 

You could store the information in a App.config file and use the AppSettingsReader class to access the data.

EDIT: Seeing that you don't want to query the information multiple times, you could use a Singleton to access and cache the data.

phsr
A: 

Presumably your objects will be required as long as the application's main form is open. If so, simply store them as properties of the form.

AdamRalph
That's a good solution, unless the data has to be saved between instances
phsr
How would I reference it from a sub Control? Application.*?
Chris Klepeis
I would rather not code my controls so they try to access custom members of the parent form. I think it would be better to explicitly pass the required references/values to the control.
AdamRalph
+1  A: 

Singletons are bad, m'kay? ;)

Or, more to the point, global data (especially mutable global data) is generally not a good thing. It makes classes difficult to test and debug. Small scope is good scope.

One option is to look at an IoC Container library (aka a DI framework).

IoC = Inversion of Control DI = Dependency Injection (or Inversion)

Basically you can set up constructors on your classes that need access to the global data and add a parameter of your "singleton" type - except it's not a singleton, just a Plain Old Object (or interface). Then you tell the Container that your "global data" class has a long lifespan, and use the Container to create your other objects. You won't use the "new" keyword much anymore. The benefit is that the Container will automagically wire everything up for you, creating one and only one instance of the global class and injecting it in to all of the other constructed objects.

Here's an (incomplete) list of the libraries/frameworks for .NET:

IoC Container Benchmark

Ninject's another one. I use Unity, but that doesn't mean it's the best for you. Here's another list: http://elegantcode.com/2009/01/07/ioc-libraries-compared/

TrueWill