The stateless nature of the Http protocol brings quite a deal of concerns about the handling of the IObjectScope in a web application. Few questions usually arise when dealing with entity containers (like the DataContext in Linq to SQL or the IObjectScope in Telerik OpenAccess ORM): where to initialize the scope, where to dispose it, how to integrate with the Page’s lifecycle, etc.. In this post we share our views on the best-practices approaches that secure safe and consistent use of the IObjectScope in web scenarios.
The desired result of the used patterns is to have one object scope, initialized on every postback and shared between various pages, or user controls that are part of a web application.
The first approach (and maybe the easiest way of accomplishing that goal) is using a Master Page. It’s is very easy to have the object scope as a member of the Master Page and then access it from any page that has the appropriate master page set. That way the scope initialization is done in only one place and the code is efficiently used e.g. we save repeats of the same code in various places.
The disposal of the scope is maybe as important operation and we are executing it in the same generic manner – in the Page_Unload event handler of the master page.
Accessing the object scope now is really easy. Loading it in Page_Init on any page that requires it is a common way of working with it.
This approach of handling the object scope has its faults as well. The most obvious one – projects that do not use Master Pages, or more concerning, projects that can’t use such pattern like most CMS web applications could not benefit from this approach.
The solution that was proven as very successful so far is using the HttpContext.Items collection to store the object scope and access it from any independent component on the page. We implemented a sample ScopeFactory helper class that provides the necessary logic for the operation:
From here on, every component in the web application obtains the object scope in the same generic manner:
So, to summarize in the end, there are numerous ways of handling the object scope when working with OpenAccess. After all it is a choice that the developer has to make. These two have proved to cover most of the user cases.
Subscribe to be the first to get our expert-written articles and tutorials for developers!
All fields are required
We see that you have already chosen to receive marketing materials from us. If you wish to change this at any time you may do so by clicking here.