asp.net - Abstracting HttpContext Request and Session - thread safety -

i have following assemblies in asp.net app:

website - asp.net website classlib - class lib contains business logic

class lib needs interact httpcontext session , request objects. code upgrade old asp app, i've hoovered vbscript contained logic , put vb.net. didn't have time rewrite.

instead of classlib interacting directly httpcontext, thought bad , prevented unit testing, introduced following abstraction layer:

public class request  private shared _requestwrapper irequestwrapper      public shared readonly property requestwrapper()                     if _requestwrapper nothing                 throw new exception("_requestwrapper null.  make sure initrequest() called valid parameters")             end if             return _requestwrapper         end     end property       public shared sub initrequest(byref requestwrapper irequestwrapper)         _requestwrapper = requestwrapper     end sub       public shared function getval(byval key string) object         return requestwrapper.getval(key)     end function 

etc.

this means in unit tests can supply own mockrequest object request class, simple namevalue collection. code in classlib , website use request class , none wiser isn't coming httpcontext, rather mock class.

when comes real deal, have following (c#) class:

public class realrequest : irequestwrapper     {         public void initialize(httpcontext context)         {         }          #region implementation of irequestwrapper          public object getval(string index)         {             return httpcontext.current.request[index];         } 

etc.

this initialised in session_start of global.asax in website, follows:

 protected void session_start(object sender, eventargs e)     {           irequestwrapper requestwrapper = new realrequest();         websession.request.initrequest(ref requestwrapper);     } 

i think similar static gateway pattern.

now, aware of singletons , static vars in multi threaded environment such asp.net, different. when gets down requestwrapper.getval(), going httpcontext running thread - , pulling value that.

certainly, concurrent tests multiple users hitting same server have never shown strange behaviour.

i'm looking re-assurance sound design, , if not why not?

thanks duncan

this fine. have similar case in our applications either uses httpcontext if exists or fake implementations otherwise.

the 1 thing watch out there specific instance httpcontext.current return value httpcontext.current.request throw exception when triggered application_start event. in framework code, don't know (or want know) triggered call though.

workaround httpcontext.hiderequestresponse being internal? detect if httpcontext.request available?