Hi,

>Or if you're hung up on this whole idea of one big mega object:

This is the crux of it - Michel wants to use his existing framework object and make it threadsafe with as little change as possible. And the safe way is to instantiate a new object for every hit. Given that I think we're both suggesting the same thing - using a static constructor and static properties for truly global values to reduce the creation overhead...

Like you I wouldn't start from here but given that Michel is where he is....
Regards,
Viv


>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.