Using a single ISession during page execution?

ssmoot · **Joined:** Fri May 13, 2005 7:46 pm **Posts:** 17

It seems like this would be ideal since lazy-loading requires the original session (I believe).

I also already have a custom Page class that derives from System.Web.UI.Page.

So I'm thinking that a Property like this:

Code:

      ISession _dataSession;
      ISession DataSession {
         get {
            if(this._dataSession == null || !this._dataSession.IsOpen) {
               if(this._dataSession != null) {
                  this._dataSession.Close();
               }

               this._dataSession = Database.GetSession();
            }

            return this._dataSession;
         }
      }

      public override void Dispose() {
         if(this._dataSession != null && this._dataSession.IsOpen) {
            this._dataSession.Close();
         }

         base.Dispose ();
      }

Is a clean way to keep alive a session for lazy-loading, and it trims down on some calls to the SessionFactory.

The downside is that the Session might get a bit bloated, but since it's only alive for the life of the Page, that doesn't seem like a big deal, and the lazy-loading and code-clarity is a bigger concern in most situations I think.

What do you guys think?

martijnb · **Joined:** Sat May 14, 2005 8:40 am **Posts:** 130

This looks fine, but you might consider storing the session in the Context.Items collection for greater flexibility.

In the Application_BeginRequest (Global.asax or custom HttpModule) event you obtain the session and store it in the Context.Items collection. From there it can be used at every place during the entire page lifecycle. Finally in the Application_EndRequest the session is closed.

ssmoot · **Joined:** Fri May 13, 2005 7:46 pm **Posts:** 17

Took me a few minutes to get how your suggestion is anymore flexible, but I think I do now. For example, I could have a class that needs to access the ISession that's called from the Page, but doesn't itself have a handle on the page. Instead of "Page page = Context.Current.Handler as Page" (something like that), I could just goto Context.Items. That about right?

That does certainly seem cleaner. (If I got it right.) Thanks for the input!

martijnb · **Joined:** Sat May 14, 2005 8:40 am **Posts:** 130

ssmoot wrote:

TInstead of "Page page = Context.Current.Handler as Page" (something like that), I could just goto Context.Items. That about right?

That's right. I could have been more clear about flexibility. What I meant was that the Context.Items solution removes the requirement to inherit from a specific base class for the aspx pages.