>I think you're hung up on the fact that some of your App object operations are static and some are dynamic. This is a problem of composition. Things like Initialize() should probably be static and fire only once. Other settings that need to be assigned at runtime to forward your object around needs to be dynamic. You can do this with proper object composition.
>
>Since the static object is always available to anything in your application you can simply create an oAPP class and an oSettings class. oSettings can do whatever it needs to dynamically by creating an instance and setting properties that are private. oSettings then can read it's initialization values from oApp (or whatever static members) so that you don't refire expensive code over and over.
>
>
>I gave an example of this before:
>
>App.Configuration
>
>in my framework is a static property which is fired the first teim the Configuration object is accessed. On that first load it reads configuration values from web.config. On any subsequent access the object already exists so that expensive web.config read access only occurs for the very first time.
>
>If I now have a request specific process object say - oProcess - I can instantiate that process object:
>
>MyProcess oProcess = new MyProcess();
>oProcess.spinCount = App.Configuration.SpinCount;
>oProcess.ConnectionString = App.Configuration.ConnectionString;
>oProcess.Request = HttpContext.Current.Request;
>
>etc.
>
>Or if you're hung up on this whole idea of one big mega object:
>
>oProcess.oApp = App;
>
>so you can always get at the config settings directly through oProcess.oApp.Configuration.ConnectionString. But this really isn't necessary because App is always in scope on its own. Same with Request and Response of the HttpContext object.

Yes, the framework, so far, was only doing its initialization once. But, we later discovered that the pattern needed to be adjusted because of hits arriving simulataneously, as I thought this was independent per page but it was not in reality as this global object defined at the global.asax level was application specific.

Then, to make sure I resolve the issue, at first, I designed a WebForm class that I inherit in all the pages. I understand I will do some enhancements in the design, but it is good for me to have the WebForm class for other specific needs.

Your suggestion of breaking down the application/process business logic is what I will look for. So, on every hit, I will only create a process object as I will have the ability of using an application object for global settings and methods only.

So, basically, I would need to reverse the order of the hierarchy here. oProcess would then become the object which will handle all hits and the application specific settings and methods object would then fall under it under oProcess.oApp.

By tieing everything together, I would be able to obtain a reference to whatever I need by simply using the oProcess hierarchy would make it much easier in development. That was the reason why I created an application property for Request and Response, such as oApp.oRequest and oApp.sResponse. The design was done to support the use of oApp to get a reference to everything.

I understand that using the object approach in the global.asax would allow me to create the application object. This has been the case so far and will remain. However, process specific business logic would now fall into a new class for the process. On every hit, from WebForm, I will simply create an instance of the process class as oProcess and will tie the application object to it.