Код UI должен использовать такие принципы ООП, как наследование и инкапсуляция, ровно как код любого другого слоя. Кроме того, некоторые принципы SOLID, могут и должны быть применены при разработке наших юзер-контролов и веб-страниц. Так как ASP.NET WebForms по-прежнему широко используется, и я полагаю, что так продлится еще долгое время, в этой статье, я предлагаю тот набор правил для программирования и проектирования, который я использую в своих ASP.NET проектах. Надеюсь, что следующие правила помогут вам сделать ваш UI код более чистым и и облегчат его поддержку в дальнейшем.
1. Используйте собственный базовый класс для классов пользовательского интерфейса
Начинайте проект со создания крайней мере двух базовых классов BasePage и BaseUserControl и наследовать от них все ваши веб-формы и юзер-контролы. Это считается хорошим стилем. Причина в том, что у вас непременно возникнет необходимость реализовать общий код для всех или части ваших веб-форм или юзер-контролов.
К примеру, все страницы вашего сайта должны иметь название и, в дальнейшем, некоторым мета-теги. Добавление свойства PageID, а также метода, который вернет название страницы и ее мета-теги будет довольно легко достигнуть при помощи наследования, а поддерживать код, очевидно, станет намного легче.
Другим распространенным случаем является необходимость показать / скрыть элементы веб-формы, в зависимости от определенного условия. Добавив виртуальный метод в базовый класс, который вызывается при возникновении события OnPreRender, вы сможете реализовать механизм скрытия и отображения элементов веб-формы. И весь этот код будет удобно расположен в одном методе и работать для всех классов-наследников, пока вы не переопределите его. Следующий код демонстрирует все вышесказанное, используя дизайн-паттерн "Шаблонный метод"
Пример:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Collections.Specialized;
using System.Data;
public class BasePage : System.Web.UI.Page
{
protected override void OnPreRender(EventArgs e)
{
base.OnPreRender(e);
DoEnableDisableControls();
SetTitleFromCMS();
SetMetaTagsFromCMS();
}
public string PageID
{
get;
set;
}
/// <summary>
/// Overwrite this method to enable or disable controls
/// depending on the state of the page.
/// </summary>
protected virtual void DoEnableDisableControls()
{
}
private void SetTitleFromCMS()
{
if (String.IsNullOrEmpty(PageID))
return;
//Queries the CMS for the page title
this.Title = "Whatever we got from the CMS";
}
private void SetMetaTagsFromCMS()
{
//Queries the CMS for the MetaTags
//add the meta tags
}
}
Странице, которая наследуется от базового класса, будет просто необходимо установить свойство PageID – и она будет иметь заголовок и мета-теги (обратите внимание на возможность задать PageID непосредственно в директивах .aspx файла страницы).
<% @ Page Language = "C #" PageID = "DefaultPage" AutoEventWireup = "True" CodeBehind = "Default.aspx.cs" Inherits = "% ExtRefWebApp._Default">
Использование такого базового класса, позволит вам внедрить общий код в любое время процесса разработки, и это будет очень полезно при будущей доработке всех страниц-наследников.
2. Скрывайте переменные сессии
Ниже перечислены причины, почему я никогда не использую переменные сессии непосредственно в коде, а инкапсулирую в отдельные классы:
- Переменные сессии широко используется в веб-приложениях. Они очень полезны, но мы не должны забывать, что переменная Session, с точки зрения ООП – это ничто иное, как глобальная переменная.
- При отладке или поддержке веб-приложений, мы часто сталкиваемся с участками кода, которые используют значения, хранящиеся в Session, и нам необходимо проверить, где эти значения были установлены. И это не легко выяснить.
- Session может содержать любой тип. Если мы заменим тип значения, хранящегося в определенном ключе Session, нам придется проверить весь код и изменить все приведения типов (мы делаем это с помощью поиска/замены текста в коде).
- Конкретного ключа Session может не существовать, либо он может иметь значение null. Не существует способа для того, чтобы получить по умолчанию для несуществующего ключа Session и, таким образом, всякий раз, когда мы используем переменную сессии, мы должны проверить ее значение (на null) перед использованием.
Лучший способ избежать этих проблем – создать набор классов, по средствам установки свойств которых мы и будем изменять значения Session. При помощи функции Visual Studio "Find all references"/"Find Usages", из контекстного меню при клике на сеттере свойства, вы найдете все объекты, которые устанавливают переменную сеанса. С другой стороны, если мы изменим тип значения в переменной Session, то код, использующий старый тип просто выдаст ошибку компиляции, следовательно, эти ошибки будет очень легко найти и сделать все изменения или оценить объем работы, необходимой, чтобы сделать изменения. Это ужесточает контроль типов и делает наш код более безопасным.
Доступ к значениям Session должен быть инкапсулирован в разных классах, и если их будет слишком много, то, желательно, чтобы они принадлежали одному пространству имен и находились в одной папке, это облегчит их поддержку.
Можно еще много всего сказать об использовании Session. Например, если сессии используются в чистом виде (без обвертки в специальный класс) не только в слоях пользовательского интерфейса, но и слоях бизнес-логики приложения; то уже излишне говорить, что в этом случае мы нарушим принцип инкапсуляции и принцип изоляции слоев приложения. Ведь теперь слой бизнес-логики зависит от HTTP контекста (мы больше не можем повторно использовать его в не HTTP приложениях).
3. Не создавайте глубокой иерархии UI-контролов
Пользовательские элементы управления в ASP.NET являются очень хорошим средством для повторного использования кода пользовательского интерфейса. Однако, когда мы начинаем вставлять одни юзер-конролы в другие, то, в конце концов мы получаем бесконечное дерево вложенных друг в друга элементов управления . Это превращает поддержку приложения в настоящий ад.
Обычно, это хорошая привычка ограничить дерево максимум на 2 или 3 уровня. Страница содержит элементы управления, которые могут содержать другие элементы управления. Но внутренние элементы должны содержать только базовые элементы управления .NET Framework (или элементы управления веб-сервером). И даже на одном уровне, мы должны ограничивать число юзер-контролов, включенных в родительский юзер-контрол. В том смысле, что создание одного большого юзер-контрола, который содержит множество внутренних юзер-контролов – это не всегда хорошая идея. Имейте в виду, что сама страница может содержать столько контролов, сколько вы пожелаете: я заметил, что очень часто разработчики не используют базовые контролы ASP.NET, а встраивают все в пользовательский Сверх-элемент управления, который в свою очередь, содержит дочерние элементы. Зачем нам добавлять этот уровень косвенности и сложности? Страница – это прекрасный контейнер для элементов управления.
4. Не все должно быть включено в отдельный пользовательский элемент управления
Если мы не уделим этому должного внимания, то, вскоре, мы получим огромное количество лишних юзер-контролов в веб-приложении. Чтобы избежать этого, я обычно следую следующим правилам, с тем чтобы определить, действительно ли функциональность интерфейса должна быть в отдельном элементе управления:
- Повторное использование: если мы знаем, что этот контрол будет использоваться в другом месте, надо вставлять его в пользовательский элемент управления,
- Правило комплексности: Иногда лучше отделить некоторые части пользовательского интерфейса, потому что мы хотим инкапсулировать некоторые сложные участки кода в отдельный класс и файл. Это не что иное как принцип эдиной ответственности, применяющийся для компонентов пользовательского интерфейса.
Например, крупную форму, которая содержит несколько разделов, значения которых которые могут зависеть друг от друга. Она будет реализована эффективней, если мы выделим эти разделы в отдельные контролы и заставим их обмениваться данными по средствам событий так, как описано в следующем пункте.
5. Используйте события для обмена данными между юзер-контролами и их контейнерами
Использование свойств пользовательских элементов управления, чтобы сообщить о своем состоянии своему контейнеру – это типичная схема, которую мы видим в веб-разработке. В большинстве случаев разработчики устанавливают переменную сессии, когда что-то случается в пользовательском элементе управления, и контейнер (будь то страница или другой пользовательский элемент управления) проверяет значение переменной сессии для того, чтобы определить, действительно ли что-то случилось или нет. Это обычно делается в событие "OnLoad". Наверное, вы заметили, что очень быстро, мы, в итоге, получаем довольно беспорядочный код в этом обработчике событий.
Во-первых, мы должны гарантировать, что код, который устанавливает переменную сессии выполняется перед кодом, который проверяет ее значение. Кроме того, мы должны гарантировать, что значение переменной сбрасывается: в противном случае, в следующий раз, когда мы попадаем на ту же страницу, мы можем спровоцировать событие, без всяких на то причин.
Один элегантный способ уведомить об изменение статуса одного элемента другому – это создать событие, на которое можно будет подписаться (прим.: public event в C#). Есть много преимуществ такого подхода:
- Чистый код, который реагирует на конкретные события с внутренних контролов,
- Один и тот же механизм может быть использован для стольких контролов, сколько мы пожелаем,
- Мы будем уверены в том, что наш контрол будет извещен только в том случае, если событие действительно произошло; в то время как использование переменных сессии добавляет неопределенности, поскольку мы не знаем, какой код выполняется первым: код, который установил значение Session, или код, который проверяет его.
- Мы не должны заботиться о переменной сессии и сбрасывать его после событий, поскольку мы больше не используем их.
- Мы не используем значения Session просто для того, чтобы поставить/считать флаг (а это экономия памяти и уважение основных принципов ООП).
6. Избегайте встраивания C#/VB кода в файлах ASPX
Лучшее место, чтобы добавить программный код в веб-формы – это code-behind файл. Внедрение кода в файлы ASPX делает его грязным и очень трудно поддерживаемым, как в старые времена ASP.
7. Используйте декларативный стиль программирования как можно чаще
Если вам необходимо настроить пользовательский или любой другой серверный элемент управления – сделайте это по средствам свойств в ASPX-файле вместо code-behind. Конечно же, бывают ситуации, когда у нас нет выбора, где настроить элемент управления (условные значения, например), но, в общем, это делает код HTML более четким и облегчает его поддержку, поскольку мы знаем многое о контроле, просто взглянув на один ASPX файл (и нет необходимости смотреть в code-behind файл).
8. Будьте осторожны при использовании статических переменных
Статические члены являются общими и сохраняют свое значение до тех пор, пока работает процесс ASP.NET. Это означает, если вы используете статические члены, вы потребляете память, которая не будет освобождена, пока вы не сделаете это явно.
Один пример я видел в прошлом, проект хранил пользовательскую информацию в виде статического словаря (между прочим, это может быть любой тип коллекции). При нагрузочном тестировании, использование памяти приложения выросло до 12 ГБ на пару сотен пользователей. Так как словарь хранился в статической переменной, ее размер увеличивался при добавлении новых пользователей и, в конце концов, мы получили исключение "Out of memory".
В данном конкретном случае, мы должны были использовать таймер и метод, который очищает время от времени словарь, чтобы избежать ситуации, описанной выше. Хотя, мы все таки удалили словарь и получали информацию из базы данных каждый раз когда это было необходимо коду, (без кэширования).
9. Рассматривайте производительность с точки зрения клиента
Когда мы говорим о производительности, то часто фокусируемся только на код, который выполняется на сервере, и пренебрегаем пропускной способностью сети и количеством загрузок страницы. Хотя процессор и память дешевле увеличения пропускной способности сети, с другой стороны, пропускная способность является более широкой при работе в контролируемой среде интранет, но мы не имеем никакого контроля на имеющуюся пропускную способность для пользователей веб-сайта в сети Интернет.
Существуют различные средства и способы, чтобы сделать производительность страницы лучше на клиентской стороне (хорошей отправной точкой, будет эта статья: http://www.codeproject.com/KB/aspnet/PeformanceAspnet.aspx).
В коде на серверной стороне, мы не должны допускать чрезмерного использования ViewState. С одной стороны, хранение дерева объектов в ViewState может показаться полезной и более эффективным техникой, чем сохранять его в сессии, ведь объект не будет висеть на неопределенное время в памяти. Но, эффективность будет еще хуже, поскольку на самом деле ваше дерево объектов будет сериализовано и передано как часть ответа в браузер клиента. И когда клиент отправит форму, сериализованный объект отправляется обратно на сервер.
Другой проблемой является количество Javascript файлов, которые загружаются вместе со страницей. Мы должны объединить их с помощью ScriptManager (см. http://bellouti.wordpress.com/2008/09/14/combining-javascript-files-with-ajax-toolkit-library/ ).
Существует слишком много тем, посвященных оптимизации на стороне клиента, которые просто не реально раскрыть в одной статье, и приведенные выше две ссылки послужат вам хорошей отправной точной, если вы никогда раньше не рассматривали этот момент.
10. Используйте кэширование, где это только возможно
Пользовательские элементы управления можно кэшировать с помощью директивы OutputCache. При создании пользовательских элементов управления, которые должны показываться содержание, взятое из БД или внешних источников, следует рассмотреть возможность использования этой директивы.
Мы также можем кэшировать данные в статических членах или пользования объектами кэширования EnterpriseLibrary. Если мы сделаем это, мы должны гарантировать, что мы создаем кэш в форме, ближайшей к той, что будет выводиться в интерфейсе пользователя. Например, если вы получаете XML из базы данных и трансформируете его по правилам XSLT в HTML, который и будет отображаться, то кэшировать следует результирующий HTML, а не XML. Кэширование HTML позволит избежать повторных преобразований XML в следующий раз, когда будет запрошена страница.
Автор статьи: Samir Bellouti
Оригинал: 10 simple rules to write better ASP.NET applications
Перевод: Дмитрий Жарий
Такой тип программиста может успешно сыграть роль Гэндальфа во "Властелине колец". У него (или у нее! :) длинная борода по колено, глупая шляпа; может носить плащ или накидку зимой. К счастью для команды, на рабочем месте, это адепт белой магии, прямо как Гэндальф. К несчастью для команды, они должны будут терпеть часы рассказов Гэндальфа о том, как он или она шел в гору, по снегу, чтобы доставить перфокарты в далекий вычислительный центр. Гэндальф ¬¬– это ваш наилучший ударник IT-шного труда, но если вы попробуйте оставить его позади команды – это вызовет отчаяние.
В любой другой профессии, Мученик – это обычный "трудоголик". Но в области разработки, мученик выходит за эти рамки в другое измерение. По крайней мере, трудоголики уходят домой, в душ – и спать. А мученики гордятся тем, что просыпаться на рабочем столе среди пустых коробок из-под пиццы. Проблема в том, что никто не просил Мученика так работать. И он или она пытается заставить остальную часть команды почувствовать себя виноватыми, такими фразами как: "Да, пойду я домой, хотя бы пообедаю. Сегодня ночью закончил с участком кода, на который отводились ближайшие три недели.
Следите за Фанатиком. Если он или она настигнет вас врасплох, и прижмет в угол, то вы будете обречены, прослушать трехчасовую лекцию о превосходстве Opera по сравнению с Firefox, или почему Playstation 3 лучше, чем XB 360. На рабочем столе Фанатика разложены плакаты, фигурки и другие безделушки, связанные с его навязчивыми идеями, скорее всего, привезенные из Японии. С фанатиками невозможно иметь дело, они тратят настолько много времени на свою одержимость (внутри и вне офиса), что они совершенно не понимают, когда нужно выполнять работу, для которой их наняли.
Это человек около сорока лет, который живет в далеком к 1984 году. Длинные волосы, потертые стираные джинсы и бандана. На протяжении рабочего дня, 
Ниндзя это самый ценный человек в вашей команде, хотя об этом никто и не знает. Подобно легендарным самураям, вы не знаете находиться ли он в офисе, работает ли он, но вы обнаруживаете доказательства, представленные в первой половине дня. Вы проверяете систему управления версиями и видите, что в 4 утра Ниндзя решил ту проблему в коде, на которую вы планировали потратить всю следующую неделю, и вы даже не знаете, что Ниндзя было известно о проекте! Видите ли, пока вы были на еще одном совещании, Ниндзя работал.
Теоретик знает все, что нужно знать о программировании. Он или она может посвятить четыре часа лекции об истории непонятного языка программирования или предоставление доказательств того, что код, который вы написали не совсем оптимальной и вполне может потратить три лишние наносекунд для запуска. Проблема в том, что теоретик не знает ничего о процессе разработки программного обеспечения. Теоретик пишет код, который настолько изыскан, что простые смертные просто не могут найти в нем смысл. Его или ее любимая техника программирования – это рекурсия, и каждый блок кода настолько разогнан до максимума... в ущерб срыва сроков и нечитабельности.
Ковбой – это стихия, которую нельзя остановить. Он или она – это почти всегда эффективный программист, который может сделать работу два или три раза быстрее, чем кто-либо еще. Проблема в том, что, по крайней мере, половину всей этой скорости происходит путем срезания углов. Ковбой считает, что заливка кода в систему контроля версий занимает слишком много времени, хранения конфигурационных данных вне самого кода занимает слишком много времени, общение с кем-либо занимает слишком много времени ... ну, вы поняли идею.
Вы видели фильмы, где единственным Коммандос, сброшенный с воздуха в глубокий тыл противника, выходит оттуда с секретными стратегическими документами, планами противника, и спасает сотни военнопленных? В команде разработчиков ПО -- это Десантник. Десантник -- это последняя надежда, чтобы спасти умирающий проект. У десантников не хватает терпения для того, чтобы работать на долгосрочной основе, но их лучшие качество -- это способностью, быстро изучить незнакомый код и как работать с ним. Другие программисты могут потратить недели или месяцы для того, чтобы изучить все необходимое о проекте для эффективной работы над ним. У Десантника это займет несколько часов или дней. Десантники могут не изучать всего необходимого для работы с основным кодом, но их скорость и высокая обучаемость помогут преуспеть там, где вся команда может потерпеть неудачу.
"Достаточно хорошо" это лучшее, что вы можете получить от Посредственного Человека. Он или она всегда тратят больше времени для создания худшего кода, чем у кто-либо в команде. "Тише едешь – дальше будешь" – так можно описать проекты П.Ч. Но П.Ч. всегда просто "достаточно хорош" чтобы не быть уволенным.
Независимо от того в какой среде вы работаете , евангелист настаивает на том, что он может быть улучшена путем выброса всех ваших текущих инструментов и процессов и замены их на что-то другое. Евангелист – это противоположность Теоретика. Евангелиста откровенен, знает очень много о разработке программного обеспечения, но, программирует очень мало .
