Lookup class use enum, struct, public const, something else?

I'm creating a lookup class so a constant value will be used throughout all the projects. The thing is, there are several solutions to create such a thing. I could create a single class with enums, structs or constants in it or create a single class for every 'object'. I'm wondering what would be the best solution.

First I thought doing something like this:

public static class Defines
    {
        public enum PAGELAYOUT_NAMES
        {
            STANDARD = "Standard"
        }
    }

But personally I don't like using strings in enums that much. Another option would be to use a struct, which is even more ugly if you see the code:

public static class Defines
    {
        public struct PAGELAYOUT_NAMES
        {
            public static string STANDAARD = "Standaard";
        }
    }

This looks a bit better, but could be confusing when having a lot of options:

public static class Defines
{
        public const string PAGELAYOUT_NAMES_STANDARD = "Standard";
}

While typing this post, I think this will be the best/clean option:

public static class PageLayout
{
    public const string STANDARD = "Standard";
}

Any other suggestions? Filling up the project with several classes which only define some constants seem to me like a lot of overhead and clutter.

Edit It wasn't very clear in the original context, but the lookup values aren't limited to only strings. Some very good suggestions below are only possible when you use only strings, but Int's, DateTime and other types need to be supported also. Got some nice ideas from the answers here, I'll try out which one will work best in my current project.

Final implemented solution Tha开发者_高级运维nks to the suggestions below, I've implemented the lookup classes like this:

 internal class Base<T>
    {
        internal T Value{ get; private set;}
        internal Base(T value)
        {
            Value = value;
        }
    }
    public class PageLayout
    {
        public static string Standard { get { return new Base<string>("Standard").Value; } }
    }

This is based on an answer given below. Reason is because now I can use this for non-strings & integers also, which isn't really possible with an enum with a description and a resource file, even though that would feel cleaner to me.

---

Depending on what exactly it is you're doing, you probably want to look at Resources.

You define an xml file (or use the designer to help you), and it gets compiled into an assembly (either embedded, or a "satellite assembly").

Right-click the properties node under your class library in the solution explorer, click "Open" and go to the resources tab. It's pretty simple to get started from there.

Once it's set up, it's easy to get at the values from code e.g:-

String s = Resources.PageLayoutNames.Standard;

There are a few complications, but without knowing more about your app I can't advise more. The one that comes to mind is if you're unit testing ASP.NET applications you need to make sure that the resource gets embedded rather than deployed as a satellite otherwise the unit tests don't work.

They're also used for globalisation, so it's good to be familiar with them.

---

Edit:

Alternately after reading your question again, I'm inclined to ask "What do you need the string for at all?".

What are you doing that you can't do with just an enum?

enum PageLayouts
{
  Standard,
  ExtraAwesome
}

If you're trying to map text for display to an enum type, there are a bunch of ways to do that e.g. by using the DescriptionAttribute

enum PageLayouts
{
   [Description("Standard")]
   Standard,
   [Description("Extra Awesome")]
   ExtraAwesome
}

You can't give the DescriptionAttribute a resource key out of the box, though. You have to subclass it if you want to support globalisation...

---

I prefer this way using a factory style static properties. But it depends on the exact scenario. You can use string or enum as the field.

 public class PageLayout
    {
        private readonly string LayoutType;
        private PageLayout(string layoutType)
        {
          LayoutType = layoutType;
        }
        public static Standard {get {return new PageLayout("Standard");}}
    }

Then in calling code use PageLayout.Standard

---

People advise against public nested classes, so in your earlier examples Defines should be a namespace rather than an outer class.

---

I always use the

public static class PageLayout 
{ 
    public const string STANDARD = "Standard"; 
} 

approach.

I do however create more classes than one: When i use a lot of sessionvariables, i create a (public static)

class SessionNames

And i do make a difference between soultion wide constants and project wide constants.

sometimes the constants for one project (for example 20 placeholders in a PDF you have to create) have nothing to do with the other projects so i make that a project class, but when i have solution wide constants i create a class at the same place as i put my string extensions etc.