Thursday, October 04, 2007 #

Generic LoadFromCache method to reliably read data from cache.

The typical procedure to work with cache is
1.to check if item for specified key exist in a cache;
2.if yes, return it;
3.if no, create it (e.g load from database),
4.save to the cache
5. and then return it.
Some developers use the code like the following:

If (DataCache.GetCache["key"] == null)
{   // code for loading object
   ...
   DataCache.SetCache("key", obj);
}
return DataCache.GetCache["key"]; //Not good, can cause problems (at least in ASP.Net 2.0).
Sometimes SetCache is not effected immediately(or expired immediately) and subsequent GetCache returns null.

Back in 2006 I lost a lot of time trying to debug the problem in DotNetNuke "DataCache.GetCache usage pattern causes random Null reference exceptions".
Now in a different application I noticed the same unreliable pattern.

To avoid mistakes and make process of getting objects from cache consistent, I've created a Generic function with delegate as a parameter  to implement the safe pattern.

using System;
using System.Collections.Generic;
using System.Text;
using System.Web;
 
    public static class CacheHelper
    {
        public delegate object CreateInstanceDelegate();        //TODO how to declare  delegate that returns generic type?
        public static T LoadFromCache<T>(String cacheKey, CreateInstanceDelegate dlgt) where T:class 
        {
            T coll = HttpRuntime.Cache[cacheKey] as T;
            if (coll == null)
            {
                coll = dlgt() as T;
                HttpRuntime.Cache[cacheKey] = coll;
            }
            return coll;
        }
  }
Example of call, utilizing C# anonymous delegates(available starting from .Net 2.0) :
           MyClass entity =
                CacheHelper.LoadFromCache<MyClass >(sCacheKey, delegate
                {
                    return LoadFromDb(localParameters);
                });
Another article describing similar approach is The 'Reluctant Cache' Pattern
Related(sort of) links: New feature about Generics in .Net 3.5
posted @ Thursday, October 04, 2007 9:13 PM | Feedback (2)

SQL Server Stored Procedure Naming Standard Recommendations

I've included a few articles that recommend similar but slightly different SP naming standards:

SSW SQL Stored Procedure Naming Standard  [proc] [MainTableName] By [FieldName(optional)] [Action] e.g procClientRateSelect'

Practical Methods: Naming Conventions

  • Prefix all stored procedures with "p". Complete the name with the primary table affected, then the job performed. This will group all procedures for a given table in one location alphabetically.
  • Samples: pCustomerList, pCustomerSearch, pCustomerCreate, pCustomerRead

     

    Naming database objects.
     Examples: carrier_get_proc, group_client_add_proc, employee_transfer_proc

    Stored procedures should be named as: name_action_proc.

  • And finally I found the one that I consider is the more convinient(Sidebar "Database Naming Conventions" in Common .NET Naming Conventions)

    When you name your procedures use "by" for the sort order, and "for" for criteria and start them off with the logical object name that the procedure works with. This makes it much easier to find specific procedures when you have a whole pile of them in a particular database. I also see no real reason for prefixes like "usp_" as all they do is add more characters to the name. Keep it simple, useful, and informative. 
    Examples :     CustomerGetSingleForID,CustomerGetListAllByName,OrderGetListForCustomerIDByDate , CustomerUpdate,CustomerDeleteSingle, CustomerInsertSingle

    Some people put an underscore after the object name in the stored proc: Customer_UpdateSingle. That looks fine to me as well. Either way, all the procedures related to a logical entity show up in the same location in the listings and trees in the various SQL Server management programs and add-ins.

    Common .NET Naming Conventions

    http://www.irritatedvowel.com/Programming/Standards.aspx is an excellent article that describes general naming standards that I recommend to follow.

    • I use  some exceptions-additions to the rules:

  • Enumerations- sometimes it is more clear to add Enum to the name of enumeration,e.g ModeEnum instead of just Mode
  • Hungarian Notation in local, member variables and parameters.
    Often it easier to recognize the purpose of variable by adding prefix s (for string)or b(for boolean). In some functions there are parameters of object type, that are converted to string variables and prefix helps to distinguish them.
    • posted @ Thursday, October 04, 2007 1:00 AM | Feedback (0)
    «October»
    SunMonTueWedThuFriSat
    30123456
    78910111213
    14151617181920
    21222324252627
    28293031123
    45678910

    About
    Article Categories
    Archives
    Post Categories
    Links
    Syndication:

    RSS ATOM