ASP.NET 2.0中的输出缓存

Just about every ASP.NET application needs to keep track of data for a user's session. ASP.NET provides the HttpSessionState class to store session-state values. An instance of the HttpSessionState class for each HTTP request is accessible throughout your application using the static HttpContext.Current.Session property. Access to the same instance is made simpler on every Page and UserControl using the Session property of the Page or UserControl.

The HttpSessionState class provides a collection of key/value pairs, where the keys are of type String and the values are of type Object. This means that Session is extremely flexible and you can store just about any type of data in Session.

But (there is always a but) this flexibility does not come without a cost. The cost is the ease with which bugs can be introduced into your application. Many of the bugs that can be introduced will not be found by unit testing, and probably not by any form of structured testing. These bugs often only surface when the application has been deployed to the production environment. When they do surface it is often very difficult, if not impossible, to determine how they occured and be able to reproduce the bug. This means they are very expensive to fix.

This article presents a strategy to help prevent this type of bug. It uses a Design Pattern called a Facade, in that it wraps the very free interface provided by the HttpSessionState class (that can meet the requirements of any application) with a well designed and controlled interface that is purpose built for a specific application. If you are not familiar with Design Patterns or the Facade pattern, a quick internet search of "facade design pattern" will provide you with plenty of background. However, you do not have to understand design patterns in order to understand this article.

The example code shown in this article is written in C#, but the concepts are applicable to any .NET language.

What is the problem?
In this section of the article I will describe the problems with direct access to the HttpSessionState class, without the facade. I will describe the kinds of bugs that can be introduced.

The following shows the typical code written to access session-state variables.

// Save a session variable
Session["some string"] = anyOldObject;
// Read a session variable
DateTime startDate = (DateTime)Session["StartDate"];

The problems arise from the flexibile interface provided by HttpSessionState: the keys are just strings and the values are not strongly typed.

Using String Literals as Keys
If string literals are used as the keys, the string value of the key is not checked by the compiler. It is easy to create new session values by simple typing errors.

Session["received"] = 27;...
Session["recieved"] = 32;

In the code above, two separate session values have been saved.

Most bugs like this will be identified by unit testing – but not always. It may not always be apparent that the value has not changed as expected.

We can avoid this kind of bug by using constants:

private const string received = "received";...
Session[received] = 27;...
Session[received] = 32;

No Type Checking
There is no type checking of the values being stored in session variables. The compiler cannot check correctness of what is being stored.

Consider the following code:

Session["maxValue"] = 27;...
int maxValue = (int)Session["maxValue"];

Elsewhere the following code is used to update the value.

Session["maxValue"] = 56.7;

If the code to read the "maxValue" session variable into the maxValue int variable is executed again there will be an InvalidCastException thrown.

Most bugs like this will be identified by unit testing – but not always.

Re-using a Key Unintentionally
Even when we define constants on each page for the session keys, it is possible to unintentionally use the same key across pages. Consider the following example:

Code on one page:

private const string edit = "edit";...
Session[edit] = true;

Code on a second page, displayed after the first page:

private const string edit = "edit";...
if ((bool)Session[edit])
{
    ...
}

Code on a third, unrelated, page:

private const string edit = "edit";...
Session[edit] = false;

If the third page is displayed for some reason before the second page is displayed, the value may not be what was expected. The code will probably strill run, but the results will be wrong.

Usually this bug will NOT be picked up in testing. It is only when a user does some particular combination of page navigation (or opening a new browser window) that the bug manifests.

At its worst, no one is aware that the bug has manifested, we may just end up modifying data to an unintended value.

Re-using a Key Unintentionally - again
In the example above, the same data type was stored in the session variable. Because there is no type checking of what gets stored, the problem of incompatible data types can also occur.

[1] [2] [3] [4]  下一页