Змінні стану Application і Session — потужний і тому небезпечний засіб. Якщо використовувати їх безсистемно, простіше простого наробити помилок в коді, як часто бувало в старому Basic. Наприклад, наступний код створює дві змінних стану Application.
Application["Uname"]= "Wombat";
Response.Write(Application["Unamme"]);
Код в першому рядку створює змінну і зберігає в ній деякий текст. Із-за банальної друкарської помилки в імені змінної код наступного рядка створить і відобразить на сторінці нову, порожню змінну, в результаті на сторінці теж буде порожньо. В цьому випадку знайти помилку просто, чого не скажеш, якщо така помилка виникне десь в глибині структури рішень (decision structure).
Щоб уникнути подібних проблем слід упорядковувати доступ до змінних стану Application і Session. Найпростішезробити це таким чином. Для кожного необхідного елементу даних оголошуються змінні на рівні сторінки, потім при виконання обробника події Page_Load вних записуються значення змінних стану Application і Session, а при виконанні обробника події Page_Unload значення змінних, оголошених на рівні сторінки, повертаються в змінні стану. Впорядковане читання і запис змінних стану — корисний прийом програмування, який рекомендується узяти на озброєння. Наступний код ілюструє впорядкований доступ до змінних стану:
|
|
string mstrUname = "";
Private void Page_Load(object sender, System.EventArgs e)
{
// Перевірити, чи існує змінна стану.
if(Application["Uname"]!= null)
// Набути значення змінної стану.
mstrUname = Application["Uname"].ToString();
// Привласнити значення.
mstrUname = "Wombat";
// Використовувати змінну
Response.Write(mstrUname);
}
Private void Page_UnLoad(object sender, System. EventArgs e)
{
// Повернути значення в змінну стану|достатку|.
Application["Uname"]= mstrUname;
}
Увага! В разі Visual C#, перш ніж викликати будь-які методи змінної стану, наприклад ToString (), обов'язково переконайтеся, що її значення відмінне від null, інакше ви отримаєте помилку часу виконання із-за порожньої змінної стану.