How to handle strings that are accessible application wide?

Question

I'm working on a WPF Prism application and have two situations where it would be preferable to have strings that are accessible across the system.

The first are the names of my views. The names of the views are used when setting up the view, as well as navigating to the view. I want to avoid typos in the view names. There's also a chance that these names could change in the future, and it's not a good idea to rely on memory to find every instance of where that view is used. The second case is for the name of different claims, in the sense of claim based authentication.

Should I be creating these as constants, despite the possibility of the strings changing? Perhaps making them readonly would be preferred? Thanks for your input!

Answer 1

I would create a class with all the constants and keep all the constant values there. You could create a project that is shared among all other projects.

Answer 2

I would definitely use storage class in common assembly for this. Something like this:

public static class Claims
{
  public static readonly String View = "http://schemas.mycompany.com/claims/view";
  public static readonly String Edit = "http://schemas.mycompany.com/claims/edit";
  public static readonly String Upvote = "http://schemas.mycompany.com/claims/upvote";
}

Microsoft uses similar approach
That leaves only one dilemma: const vs readonly. I'd recommend to use readonly in your case, because you said there is a possibility of changing. Const should be used only if data is actually constant, because constants are not referenced, but copied to each referencing assembly. E.g. if you define constants in assembly A and use them in assembly B, then if you change them in A, you'll have to recompile B, otherwise B will keep old version of these constants.

Answer 3

A common assembly storage class may be simple enough for your needs, but you may want to consider using a .resx file. It's essentially a XML format file where you hardcode your strings and you can then reference inside your code. MSDN Documentation

Here's some compelling reasons to use them:

• Resource files give you an easy way to localize/internationalize your .net applications by automatically determining which language resx file to use based on the user's locale. To add more languages, simply add another translated resource file.

• Resource files give you a central location to store your strings, files and scripts and refer to them in a strongly-typed manner (so the compile will break if you reference them improperly).

• Resource files can be compiled into satellite assemblies, making it easy to change up the resources in a production application without having to recompile the whole thing.

What are the benefits of resource resx files?

You can read from the resx as so:

var <Variable Name> = Namespace.Properties.Resources.<Resource Name>

Answer 4

I'm confused with the answers given. All UI strings should always be in the string table. That's what its there for. Its accessible system wide. Plus you can localize.