| . 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;...
i 上一页 [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] 下一页 |
