Инкапсулируйте навигацию в главной странице1, чтобы обеспечить ее единообразие по всему приложению. Однако избегайте указания путей перехода в коде приложения. Также обеспечьте, что пользователи могли переходить только к представлениям, для просмотра которых они авторизованы.
Предусмотрите карту сайта, она поможет пользователям находить необходимые страницы, а поисковым механизмам просматривать сайт в случае необходимости. Используйте в UI визуальные элементы, такие как встроенные ссылки, навигационные меню и «хлебные крошки», чтобы пользователи понимали, где они находятся, что предлагается на сайте и как перемещаться по сайту быстро. Предусмотрите мастеры для реализации предсказуемых переходов между формами.
Компоновка страницы
Дизайн приложения должен обеспечивать отделение компоновки страницы от конкретных компонентов UI и логики обработки UI. При выборе стратегии компоновки необходимо учесть, кто будет создавать компоновку: дизайнеры или разработчики. Если этим будут заниматься дизайнеры, выбирайте такой подход к компоновке, который не требует написания кода или использования инструментов разработки. При проектировании стратегии компоновки руководствуйтесь следующими рекомендациями:
По возможности максимально используйте для компоновки Каскадные таблицы стилей (Cascading Style Sheets, CSS), а не компоновку на базе таблиц. Однако если требуется отображать сетку или если данные представлены в виде таблицы, должна использоваться компоновка на базе таблицы. Не забывайте, что формирование визуального отображения компоновки на базе таблицы может занимать довольно много времени, также сложная компоновка может приводить к различным проблемам.
Постарайтесь максимально унифицировать компоновку страниц, чтобы обеспечить понятность и простоту работы с ними. Не создавайте большие страницы, выполняющие множество задач, особенно если с каждым запросом обычно выполняется лишь несколько задач. Максимально сокращайте размер страницы, чтобы обеспечить наилучшую производительность и снизить требования по пропускной способности.
В ASP.NET-приложениях используйте шаблоны страниц для обеспечения общего внешнего вида и поведения для всех страниц и обновления сайта с минимальными трудозатратами. Общие разделы страниц вынесите в отдельные пользовательские элементы управления, это поможет упростить компоновку в целом и обеспечит возможность повторного использования этих элементов управления.
Использование серверных элементов управления ASP.NET AJAX и библиотеки на стороне клиента ASP.NET AJAX упростит перенос клиентского сценария между
1 Подразумевается шаблоны в виде Master Page, а не только стартовая страница сайт (прим.
научного редактора)
разными браузерами. Также не смешивайте клиентский сценарий с HTML-кодом, это усложняет обслуживание страницы. Размещайте его в отдельных файлах сценария, чтобы обеспечить возможность их кэширования браузером.
При миграции существующего Веб-приложения используйте на ASP.NET-страницах элементы управления Silverlight, это обеспечит насыщенное взаимодействие с пользователем и максимально сократит необходимость в реорганизации приложения.
Формирование визуального отображения страницы
При проектировании стратегии формирования визуального отображения страницы необходимо обеспечить эффективность этого процесса и максимальное удобство использования интерфейса. При выработке стратегии формирования визуального отображения руководствуйтесь следующими рекомендациями:
Использование сценария на стороне клиента или ASP.NET AJAX обеспечит лучшее взаимодействие с пользователем и меньшее время отклика за счет снижения числа необходимых обратных передач. Применение собственного клиентского сценария может усложнить тестирование приложений, поскольку разные браузеры и версии реализуют разную поддержку сценариев. Лучше используйте ASP.NET AJAX, который поддерживает большинство популярных браузеров. Не забывайте, что использование любого кода на стороне клиента (включая сценарии, порождаемые встроенными элементами управления ASP.NET) может неблагоприятно сказываться на доступности. Обеспечьте соответствующую поддержку специальных возможностей для специализированных агентов1 и пользователей с ограниченными возможностями.
Рассмотрите возможности привязки данных. Например, можно выполнять привязку коллекций, объектов DataReader, таблиц DataSet и собственных объектов ко многим элементам управления ASP.NET. Используйте технологии разбиения данных на страницы для сокращения проблем с масштабируемостью, обусловленных необходимостью обработки больших объемов данных, и для улучшения производительности и времени отклика.
Обеспечьте поддержку локализации в компонентах UI.
Отделите компоненты пользовательского процесса от формирования визуального отображения данных и функций запроса.
Управление сеансами
При проектировании Веб-приложения важно выработать эффективную и безопасную стратегию управления сеансами, это будет иметь большое значение для производительности и надежности. При этом следует учесть такие аспекты, как что сохранять, где сохранять и как
1 Например, роботы поисковых систем (прим. научного редактора).
долго удерживать сохраненные данные. При проектировании стратегии управления сеансами руководствуйтесь следующими рекомендациями:
Продумайте, есть ли необходимость сохранять состояние сеанса. Использование состояния сеанса обусловливает дополнительные издержки при каждом запросе страницы.
Сохраняйте данные сеанса, только если это действительно необходимо, для улучшения производительности используйте сеансы только для чтения или полностью отключайте состояние сеанса.
Если используется один Веб-сервер, требуется обеспечить оптимальную производительность обработки состояния сеанса и число параллельных сеансов невелико, храните состояние внутри процесса. Однако если воссоздание данных сеанса чрезвычайно ресурсоемко и требуется обеспечить длительное хранение данных в случае перезапуска ASP.NET, используйте сервис состояния сеанса, выполняющийся на локальном Веб-сервере. Для сценариев с использованием множества серверов (Веб-фермы), где требуется централизованное хранение данных сеансов серверов, используйте хранилище состояния SQL Server.
Если данные состояния хранятся на отдельном сервере, защитите канал связи для передачи состояния сеанса с помощью таких техник, как SSL или IPSec.
Для снижения затрат на сериализацию отдавайте предпочтение базовым типам при хранении данных сеансов.
Валидация
Эффективная стратегия валидации имеет большое значение с точки зрения обеспечения безопасности и надежности приложения. При несоответствующей или недостаточно полной валидации приложение может оказаться уязвимым к таким угрозам безопасности, как межсайтовые атаки внедрением сценариев (cross-site scripting, XSS), атаки типа внедрение SQLкода, переполнение буфера и другие типы атак посредством входных данных. При проектировании стратегии валидации руководствуйтесь следующими рекомендациями:
Проверяйте все данные, пересекающие границы доверия приложения. Исходите из предположения, что все управляемые клиентом данные являются злонамеренными и подлежат валидации.
Стратегия валидации должна обеспечивать ограничение, отклонение и очистку злонамеренного ввода. Проводите проверку длины, диапазона, формата и типа вводимых данных.
Используйте проверку на стороне клиента для оптимизации взаимодействия с пользователем и сокращения числа обращений к сети, но для обеспечения безопасности всегда выполняйте проверку на сервере.
Изучите решения, шаблоны проектирования и библиотеки сторонних производителей, которые помогут реализовать централизованное управление и повторное использование правил и кода валидации.