Graciously Hosted by MaximumASP        
Home
Blog
Videos Podcast Code Books About Contact

.NETOOP Global Statics Update

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…..

7-9-2009 10-21-23 AM 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

7-9-2009 10-22-05 AM

 

 

 

 

 

 

 

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:  }

 

July 13 2009 Joe Stagner 6 Comments
Filed under: Blog
Tagged as:

» Similar Posts

  1. Global Application settings and the web.config file.
  2. Proving the performance of Static Properties.
  3. Trapping Intentional Cross Site Scripting (XSS) Attempts in ASP.NET

» Trackbacks & Pingbacks

  1. Pingback from .NETOOP Global Statics Update : Misfit Geek

    .NETOOP Global Statics Update : Misfit Geek — July 13, 2009 10:47 AM

  2. Pingback from asp.net news (July 17th) - Jack is Here

    asp.net news (July 17th) - Jack is Here — July 16, 2009 9:37 PM

» Comments

  1. mellamokb avatar

    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

    mellamokb — July 13, 2009 11:01 AM
  2. Joe Stagner avatar

    That's looks interesting - I'll check it out.

    Joe Stagner — July 13, 2009 11:06 AM
  3. Ashic avatar

    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...

    Ashic — July 13, 2009 11:11 AM
  4. Andrew avatar

    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.

    Andrew — July 13, 2009 2:28 PM

Comments are closed