[Zigon]

Hi!

I was just wondering about this question, so:

First: Is it even wise to do so?
Second: If yes, which approach should one use?

Approach one: Just create a class to hold static variables. Something like this:

    class Constants
        {
        // used for holding application-wide constant values
        // like filenames
        public static  string TABLE_SHEMA_FILE_NAME = "TableShema.xml";
        public static  string APP_SETTINGS_FILE_NAME = "AppSettings.tar";
        
        }

Or approach two:

    class Constants
        {
        // used for holding application-wide constant values
        // like filenames

        public static string AppPath
            {
            get { return Application.StartupPath+@"\"; }
            }
        
        }

Or is there any other/ better/ more OOP oriented way to do it?

Thanks!

[Curtis Rutland]

It's not a bad idea. There's no need to use a static property if the value is constant, just use mark it as const instead of static (since consts are always static, you don't have to specify)

public const string APP_SETTINGS_FILE_NAME = "AppSettings.tar";

As long as you don't plan on putting anything non-static in the class, you can make the class itself static.

Just make sure the values you're putting in there really need to be application-level constants, and not something that you should be able to either make configurable (using the app/web.config) or local to a particular class.

[MrShoes]

Sure, I do it... generally if I have a server-based application I'll have a table holding global parameters, with an XML file on the users' machines holding their personal settings. This XML file I deserialize to a static class (or a class with static members). You can do similar with server-held preferences using things like EDM.

Whether you should do it depends on the type and size of the application, and how much user control you give.

[tlhIn`toq]

YOu can even decrease the layering complexity and just put these things in the Program/App class. It is already available program-wide. And it makes the calls feel remarkably natural.

using System;
using System.Windows.Threading;
using myCustomNamespace.Preferences;
using myCustomNamespace.Environment;
using Application = System.Windows.Application;

namespace myCoolProgram
{
    /// <summary>
    /// Interaction logic for App.xaml
    /// </summary>
    public partial class App : Application
    {
        #region Properties

        public static string UserDirectory
        {
            get { return Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments); }
        }

        public static string AppData
        {
            get { return User.AppData; }
        }

        public static string CompanyName
        {
            get { return myCustomNamespace.Environment.Application.CompanyName; }
        }

        public static string ProductName
        {
            get { return myCustomNamespace.Environment.Application.ProductName; }
        }

        public static Email EmailPreferences { get; set; }

        #endregion

        #region Methods

        public static void DoEvents()
        {
            if (Current != null)
                Current.Dispatcher.Invoke(DispatcherPriority.Background,
                                          new Action(delegate { }));
        }

        #endregion
    }
}

Like this, the calls to this functions/properties are simply

string temp = App.UserDirectory;
string addy = App.EmailPreferences.SenderAddress;

This post has been edited by tlhIn`toq: 15 June 2012 - 09:10 AM

[Zigon]

Wow! tlhIn`toq, I did't know about that option! It seems quite usefull.
My head bowes to you all!

[tlhIn`toq]

Remember that this class is created and run before anything else. Its what everything else is built on. If you are making a WinForms app you'll see the Program.cs class is what then calls your primary form into existance.

This makes Program.cs a good place for things like:

• Pre-launch splash screens
  
• Loading variables before your forms
  
• Checking security devices to see if the app is authorized
  
• Bubbling up exceptions that don't otherwise get handled to keep the app from crashing in an ugly way

[Zigon]

OK! But can messing with it do any harm? As As I understood, you basicly extended that class, or am I wrong?

[tlhIn`toq]

"extending" a class has a whole 'nother meaning.

This is simply using the class that already exists by giving it properties and methods.


Your car came with a radio. Suddenly after two years you turned it on. WOW! You didn't extend the car, you just started using a feature that was always there for you.

Can you do harm? Well you're not going to disable your computer.

If you start deleting stuff that was put there by Visual Studio you might stop something from functioning. That's about the worst you can do.

Overuse of this by making everything global is just bad design.
Most methods should be totally self-contained, receive parameters and return results. Don't get in the habit of making all your methods affect countless global variables just because its quick and easy: Nobody will hire you with that.

[Curtis Rutland]

Quote

Nobody will should hire you with that.

They will...sadly. I've seen too much of it in production applications to believe otherwise.

[tlhIn`toq]

Ok - Nobody worth actually working for... someplace you would want to work where you will be proud of your code... Will/should/would hire you with that.

[Zigon]

Ah! I see... Thanks again, guys! I'll keep these things in mind.