With lots of great feedback I’ve modified the “SiteGlobalSettings” class I wrote about earlier.
Though it still uses global static but the values are stored in a Global Resource File.
This affords us the superior performance of the mechanism, keeps the “editable” nature of the data, and keeps the simple API based initialization will facilitate multi-cultural implementation when we get there. (Cultural neutral settings can be stored in a single .resx where as language specific entries can be stored in language specific resource files.)
So, I created a Resource file and a sample entry…..
The class code remains the same except for the property initialization.
1: public static class SiteGlobalSettings
2: {
3: static public string MySiteName { get; set; }
4: static public string MySiteOwner { get; set; }
5:
6: static SiteGlobalSettings()
7: {
8: try
9: {
10: MySiteName = (String)HttpContext.GetGlobalResourceObject("AppResources",
11: "SiteName");
12: }
13: catch
14: {
15: MySiteName = "*NETOOP.";
16: }
17: }
18: }
Technorati Tags: Microsoft,ASP.NETOOP,Performance
Filed under:
News
RE: .NETOOP Global Statics Update
Pingback from .NETOOP Global Statics Update : Misfit Geek
How about a T4 template to generate the SiteGlobalSettings class, in the spirit of David’s T4 for webforms paths: blogs.msdn.com/…/asppathguru-a-l Then you would only have to write the resource entries, and the class would be automatic, or vice-versa. If you like the idea, I could try to put one together.
~ mellamokb
That’s looks interesting – I’ll check it out.
If that is in fact the only exception that can be thrown from within the try block (which it obviously is), then does it really matter if the catch block is empty? And even if it weren’t…would you want to see a lousy YSOD (yellow screen of death) for something as trivial? Well, if you wanna be a purist…
This looks pretty close to the Monostate pattern. I’d suggest that it may be worth taking a slight performance hit and creating
static private string _MySiteName;
This would mean you could have read-only properties and in doing so you are at least gaining the benefits of encapsulation.
Besides I can’t see the real benefit of the performance gains made on resources and config settings as they aren’t likely to be called in a tight loop hundreds of thousands of times. On a web page you are only likely to use a handful of these fields once or twice per page.
RE: .NETOOP Global Statics Update
Pingback from asp.net news (July 17th) – Jack is Here