I am considering to refactor my code by creating a static class that holds all strings in one place for messages/keys/etc used all over in the website. It would ease maintenance.
Now, my concern is the following.
From my experience in php, the speed of load was very important. I had to balance what to hardcode and what to dynamically generate.
In general, how would the loading speed be impacted by my refactoring? Since C# web application is precompiled, would this not really be an issue to consider?
Consider using Resource files to manage strings. Using Resource files have the added advantage of being much easier to Internationalize by simply adding new Resource files with different culture suffixes.
Resouces are compiled to thread safe cached classes so it's better then using static readonly fields in the static classes. The main advantage is that it's more maintainable, because
- It's a common practice
- You can use resource editor to edit strings
- It's easy to change resource location (store strings in DB for example)
- You can replace resource library without re-compiling whole website
- It's a easy to localize website
- It's easy to list all strings to translate
If you want to use a static class for constants that never change don't. Use constants:
public class Constants
{
public const string Message1 = "Here is a message";
public const int Value1 = 17;
}
In this case you can use these constants in the code like this:
Constants.Message1
Constants.Value1
The advantage is that constants are replaced to actual values during the compile time so there is no loading of class Constants
at runtime. And you can still update your constants in a single place
String is a very specific type in .NET. It is immutable (same as in many other languages). It means that if you do "str 1" + "str 2" you will get one more object "str 1str 2". So be careful with dynamic string generation. If you need to concatenate a lot of strings on runtime, consider StringBuilder class.
When you hardcode your strings in an assembly (project) .NET puts these strings into a string pool and whenever you use this string (or even create new string of the same value), .NET returns pointer to an existent string from this pool. .NET also puts newly created strings into intern pool if string is not exist in this pool.
More info about string intern pool
Typically, you would not have problems with placing all the strings into a static class. But keep in mind the information above to avoid potential performance problems and bugs.
Many people consider static variables in web applications evil because they are in global scope and break OOP principles. Others use them deliberately to get (often questionable) performance gains in web applications.
Have in mind that by using static variables you trade time
performance for space
, since your variables will allocate a constant amount of memory even if never utilized/accessed.
A fact is that you will get some response time gains, and also save some Garbage Collector work by using them.
Using static string variables might not be the best approach in terms of maintainability/flexibility. If your primary goal is to simplify maintenance using Resx resource files
is probably a safer approach, and reads will use constant time since it uses thread-safe static properties which read cached values.
However, you should always be cautious when using static variables in a web app, so I will conclude my post with the wise words of Scott Hanselman:
When using ASP.NET think twice, then think again, before throwing that static (or Shared) keyword in there. Perhaps there is a scope better suited for what you're trying to do.