Where should you store your constant strings in .NET

Where should you store y开发者_如何学JAVAour commonly used strings for error messages, notifications, etc?

I used to put it into this global class that had a number of const strings but I've also seen some where it's stored in resource files. Where is the best place to put them in? I'm using .NET btw.

---

Resx is handy if you anticipate needing to swap them out - for example internationalization or per-instance customization. But it isn't hugely hard to move them manually between them. So: is it likely to need to change?

I would say: if you do keep them in code, try to keep the constants as tightly scoped as possible; if a constant only relates to User instances, for example, put it in User.

Likewise, things that won't change shouldn't be cluttering up a resx; for example, some internal well-known string that relates to the meaning of a value in a database... probably doesn't belong in resx even if you are using resx.

---

I imagine if you ever want to translate/localize your product then resource files are going to be the best place to store those.

I am sure there are other advantages/disadvantages of both but that's the one that leaps into my head first.

---

If they are a part of your UI elements such as title etc. then put them in Resource files.

If they are a part of your program constructs such as file prefixes, internal error message strings etc. you should put them in a separate code file.

---

Anything that can be localized should be in a resource file. Even if you are 100% sure you will never need localization having strings in resource file makes that transition easy.

So titles, names, GUI labels, dialog text, error messages, etc all belong in resx. Do it now. If/when your application does need to be localized future developers will thank you.

Now other constants are a little more difficult. I don't think there is a hard & fast rule but generally I try to define "true" constants as a const with as small of a scope as needed. By true constant I mean anything unlikely to ever change over the scope of the application lifetime. I don't like to use resource file for non localized strings as it tends to break encapsulation. For example the require has size for PKDB2 function should be defined locally. Nobody outside the crypto object needs to know what it is.

Things brings up a related topic. Anything which is currently static but is likely to change in the future (even in future versions of application) should be declared readonly instead. These can be loaded from resx, personally I don't. Effectivve C# covers this in item #2.

Also a lot depends on what your company/team requires I have been on teams where nothing was in resource file and also been on teams where everything (even things I felt should be defined locally) were kept in resource file.

---

See this post you can find there some useful answers and also valuable discussion in comments.

As a general rule you should:

• think twice before creating public class with constants.
• place shown to user messages into resource files (you never knows when project will need localization)