I just discovered the error in the new page I created was because of SiteSetting is null. That is because SiteSetting was initialized in the Global.asax.cs then stored in the context. What the method SiteSetting.GetCurrent() does is nothing more than retrieve object from the context. My suggestion is let the method GetCurrent() responsible for the existence of the object, it take care everything including caching and storing object in context. This is where the caching implimentation takes place.

In the global page, instead of creating SiteSetting object, just call the GetCurrent().

Yeah, now we are talking. ActivePage does not need to be cached or stored in the Context. SiteSettings encapsulates everything. SiteSettins works like a database in memory.  Whenever the activepage is needed, just pull it from the collections. That will be faster. That is what in my to-do list. Because it is not a fast jobs, I did not get to do it; instead I just made a quick change to GetCurrent() and added another helper class. Here is what I did:

using System;
using System.Collections.Generic;
using System.Text;
using System.Web;

namespace mojoPortal.Business
{
    public class SiteSettingsHelper
    {
        #region Added by Bo on 8/26/2006
        public static SiteSettings GetCurrent()
        {
            HttpContext context = HttpContext.Current;
            //try to get it from cache
            SiteSettings setting = (SiteSettings)context.Cache[GetCacheKey];
            //no cache ?
            if (setting == null)
            {
                //create new object
                setting = new SiteSettings(Hostname, PageIndex, PageID);
                //insert into cache
                context.Cache.Insert(GetCacheKey, setting, null, DateTime.Now.AddMinutes(3), System.Web.Caching.Cache.NoSlidingExpiration);
            }
            return setting;
        }
        private static string Hostname
        {
            get
            {
                HttpContext context = HttpContext.Current;
                return context.Request.ServerVariables["SERVER_NAME"].ToLower();
            }
        }
        private static int PageID
        {
            get
            {
                HttpContext context = HttpContext.Current;
                int pageid = 0;
                if (context.Request.QueryString["pageid"] != null && context.Request.QueryString["pageid"] != "")
                {
                    pageid = Convert.ToInt32(context.Request.QueryString["pageid"]);
                }
                return pageid;
            }
        }
        private static int PageIndex
        {
            get
            {
                HttpContext context = HttpContext.Current;
                int pageindex = 0;
                if (context.Request.QueryString["pageindex"] != null && context.Request.QueryString["pageindex"] != "")
                {
                    pageindex = Convert.ToInt32(context.Request.QueryString["pageindex"]);
                }
                return pageindex;
            }
        }
        private static string GetCacheKey
        {
            get
            {
                string key = "SiteSettings";
                if (PageID > 0)
                {
                    key = Hostname + "-SiteSettings-" + PageID;
                }
                else
                {
                    //PageID = 0 or no pageid
                    key = Hostname + "-SiteSettings-default";
                }
                return key;
            }
        }
        #endregion
    }
}

In the SiteSettings class I modified the GetCurrent() method to:

public static SiteSettings GetCurrent()

{

             return SiteSettingsHelper.GetCurrent();

}

Well, the goal of SiteSettingsHelper is to cache different versions of SiteSettings based on PageID and Hostname. And to not modify the structure of the portal.

This is not what I really planned to do and it is not the best way, but it is the fast and easy way to make things work and also a quick implementation of caching. Plus, I save alot of time.

1. Measure current performance.
2. Measure performance with "dumb" output caching (i.e. neglecting security and cache invalidation issues).  This would give you an upper-bound on the effect of output caching.
3. Measure performance of "dumb" business object caching (i.e. neglecting cache invalidation issues).  This would give you an upper-bound on the effect of business object caching.
4. Measure performance of both types of caching using simplest possible cache invalidation logic (ie. any change to anything on the site invalidates the entire cache.).
5. If it is worth the extra effort, implement more sophisticated invalidation logic and/or handle the security issues associated with output caching.
6. If it is worth the extra effort, implement browser caching.  If you handled the output caching security issues in step 5, this is a no-brainer.  If not, you need to decide whether the reduced network bandwidth and server load is worth the effort to do that.