Think of the typical e-shop application: You have the customer entity, the shopping cart entity, the shopping cart item entity, the product entity,... There are quite a few entities that you can access for every page.

The usual approach is to read values from the request or session (oh my god, don't abuse the session object) in every page that they are needed, query the database and load a Dataset or business object that contains the proper data, and then use it in the page. We usually do that in almost every page, we duplicate code, and we can face the problem of different parameter names for each page: "Customer_ID", "CustomerId", "CustId"...

There are more cute solutions as to create a set of functions to build the urls and retrieve the parameters (or even better the business objects). The problem is that you have to call the functions in every page, you can create a base page and inherit all pages from it, but it can be a hassle.

What I am doing in my current project is create what I call a business context. Basically is an static object similar to the SPContext object in SharePoint, it exposes the business objects related to that page/user as properties and reads the values from the request, session or whatever method I like. The properties are lazy-initialized so there is no additional overhead if you don't use them. And the best of all, you have no code in the pages to read the values, all you have is to access the properties of that static object. The actual property values are stored as items in the HttpContext object (be careful when using static stateful objects in asp.net).

Another good point about it is that the object is "always there", so if your programmers use it you can avoid reading many times the same object form the database (it's so common... :( ).

The urls for the context to recognize are built using static functions in the object, so every time an url is created it is created the same way, overloaded with both the business object and the individual parameters, so they are very simple to use:

• public static string BuildUrlForProduct (Product item)
• public static string BuildUrlForProduct (int itemId)

The philosophical statement is that whenever you receive a "ProductId" parameter, there is a product involved, if you receive a "CustomerId" there is a customer involved, so the point is to isolate that "parameter identifying and data retrieving logic" into an static object accessible form our pages.

This solution can be even more cool when using it with REST applications, so the business objects can be more coupled with the url and request parameters (or lack of).

It may not fit 100% for all your pages in your web app, but can save you some work and will make some page's code easier to follow.

A very basic example. Shopping Cart

You create the following properties in your business context, lets call it "ShopContext":

• ShoppingCart -> We'll store it in session (as is a per visitor item)
• Product -> We'll store it in the database (as is a data of our shop)

From the customer view:

The customer is browsing your eshop, every time the user enters a product page, you can access the actual product by calling ShopContext.Product, you don't have to read from request as the logic is embedded in the accessor of the Product property. You simply fill the labels/textboxes from the properties of your object.

The customer decides to buy a product, so you access your ShoppingCart object and add an item, based on the ShopContext.Product already loaded.

The customer decides to checkout and pay, so when he goes to the checkout page, you simply read the shopping cart info from the context.

From the administrator view:

You are editing the catalog, so you access a page for editing the product data, you already have the values of the properties so you fill the form of the product, to update the product you read the values into the object and simply call update method.