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.

+++ Rick ---






>>Not quite. The sample I gave used the constructor (New() in VB if IRRC). Ordinary methods aren't quite the same. Defining ordinary methods as static means they can be called without instantiating the actual object: So given:

>>public class Framework
>>{
>>      public static string SayHello()
>>      {
>>        return "Hello";
>>      }
>>}

>>This method could be used like:

>>string s = Framework.SayHello();
>>// Rather than:
>>f = new Framework();
>>string s = f.SayHello();
>>// In fact this wouldn't be legal....
>>

>>Lots of native examples of this behaviour in the .NET framework; Guid.NewGuid() is a classic example....
>
>Thanks, I will have to see if I can switch Initialize() to a New() approach. If yes, then I would have something interesting here.