>>The real gain would be in using static constructors to initialize the Framework. It would certainly help with handling the global level properties - static constructors would, as Rick says, only run once (the very first time the framework is instantiated) - subseguent instantiations would have those properties already set - and that might reduce the initialization overhead enough to make using new Framework objects on each page hit acceptable ?
>
>Using what I have now, by creating a new application object at every hit, would static be useful for me? Because, I am executing Initialize() at every hit now.

Hi,
Definitely help. Simple example:

public class Framework
{
    public static int SomeCalculatedValue;

    static Framework()
    {
        // Lot of complicated code could be here to calculate
        // the value of SomeCalulatedValue but, for simplicity:
        SomeCalculatedValue = 5;
    }
}

The constructor code will only fire when the first instance is instantiated. All subequent instantiations (as you would be doing in, for example, Page_Init) would not run the constructor code and would share the SomeCalculatedValue. E.g:

Framework f1 = new Framework(); // f1.SomeCalculatedValue set to 5
Framework f2 = new Framework(); // Constructor code not run but SomeCalculatedValue = 5;
f1.SomeCalculatedValue = 6;  // Now *all* Framework objects .SomeCalculatedValue will be 6 as well