поддерживающий распределенное кэширование, такой как технология Memcached производства компании Danga Interactive или механизм кэширования Velocity1 от компании Microsoft. Тем не менее, если отличия между серверами не существенные или данные изменяются очень медленно, подойдет кэширование в памяти.
При работе с кэшем в памяти применяйте кэширование данных в готовом к использованию виде. Например, кэшируйте не просто необработанные данные базы данных, а используйте необходимые приложению объекты. Однако избегайте кэширования часто меняющихся данных, поскольку затраты на поддержание актуальности кэша в этом случае могут превышать затраты на воссоздание или повторный запрос таких данных.
Не кэшируйте незашифрованные конфиденциальные данные.
Не полагайтесь на кэшированные данные, они могут быть удалены. Также не забывайте, что кэшированные данные могут устаревать. Например, использование кэшированных данных недопустимо при выполнении коммерческих операций, для которых требуется извлекать самые свежие данные.
Позаботьтесь о правах доступа к кэшированным данным. В случае возможности доступа к данным пользователей, выполняющих разные роли, кэшируйте только те данные, для которых можете применить соответствующую авторизацию.
При использовании множества потоков убедитесь, что любой доступ к кэшу является потокобезопасным.
Более подробно методики кэширования рассматриваются в главе 17, «Сквозная функциональность».
Сетевое взаимодействие
Обработка длительных запросов должна реализовываться с учетом времени отклика пользователя, а также удобства обслуживания и тестируемости кода. При проектировании обработки запросов руководствуйтесь следующими рекомендациями:
Используйте асинхронные операции или фоновые потоки, чтобы избежать блокировки UI при выполнении длительных действий в приложениях Windows Forms и WPF. Применяйте AJAX для осуществления асинхронных запросов в ASP.NET. Обеспечивайте пользователю обратную связь о ходе выполнения процесса для длительных операций. Предоставьте пользователю возможность отменить длительную операцию.
Избегайте смешения логики обработки UI и формирования визуального представления.
1 В ноябре 2009 года данный продукт вошел в состав Windows Server AppFabric (прим. научного редактора).
При выполнении ресурсоемких вызовов к удаленным ресурсам или слоям, таких как вызов Веб-сервисов или запрос к базе данных, проведите анализ, возможно, будет целесообразным делать эти запросы к сервису с детализированным интерфейсом (много мелких запросов) либо с обобщенным интерфейсом (один большой запрос). Если пользователь запрашивает большие объемы данных для выполнения операции, первым делом извлекайте лишь то, что необходимо для отображения и начала работы, а затем постепенно догружайте данные в фоновом потоке или по мере необходимости (примерами такого подхода является разделение данных на страницы и виртуализация UI). Используйте более масштабные вызовы к обобщенному сервису, когда пользователю нет необходимости ожидать завершения вызова.
Композиция
Подумайте, не упростится ли разработка и обслуживание приложения, если слой представления будет использовать независимые модули и блоки представления, компонуемые во время выполнения. Шаблоны композиции UI поддерживают создание блоков представления и компоновку пользовательского интерфейса во время выполнения. Эти шаблоны также помогают максимально сократить зависимости кода и библиотек, в противном случае, каждое изменение зависимостей требовало бы проведения повторной компиляции и развертывания модуля. Шаблоны композиции помогают реализовать совместное использование, повторное использование и замещение логики представления и блоков представления. При разработке стратегии композиции UI руководствуйтесь следующими рекомендациями:
Избегайте зависимостей между компонентами. Например, по возможности широко используйте шаблоны абстракции во избежание проблем с обслуживанием. Применяйте шаблоны, поддерживающие внедрение зависимостей во время выполнения.
Создавайте шаблоны с заполнителями. Например, используйте шаблон Template View (Представление по шаблону) для компоновки динамических Веб-страниц, чтобы обеспечить единообразие и возможность повторного использования.
Используйте для создания представления модульные части, пригодные для повторного использования, например, шаблон Composite View (Составное представление) позволяет компоновать представление из модульных неделимых составляющих. Реализуйте в своем приложении разделение, применяя самостоятельные модули, добавление которых не составляет труда.
Будьте внимательны при использовании компоновок, формируемых динамически во время выполнения, что может вызывать сложности с загрузкой и обслуживанием. Рассматривайте шаблоны и библиотеки сторонних производителей, которые поддерживают динамическую компоновку и внедрение визуальных блоков и представления во время выполнения.
Для обмена данными между компонентами представления используйте шаблоны связи со слабой связанностью, такие как Publish/Subscribe. Это обеспечит снижение связанности компонентов и повышение тестируемости и гибкости.
Управление исключениями
Проектируйте для приложения централизованный механизм управления исключениями, который обеспечит единый подход к перехвату и обработке непредвиденных исключений (исключений, которые невозможно обработать локально). Особое внимание обратите на исключения, распространяющиеся через границы слоев и уровней, а также исключения, пересекающие границы доверия. При проектировании стратегии управления исключениями руководствуйтесь следующими рекомендациями:
Обеспечьте понятные пользователю сообщения об ошибках для уведомления об ошибках приложения, но убедитесь, что не включаете конфиденциальные данные в страницы ошибок, в сообщения об ошибках, файлы журналов и аудита. Постарайтесь по возможности привести приложение в согласованное состояние или, если это невозможно, обеспечьте завершение выполнения.
Убедитесь, что перехватываете исключения, которые не будут перехвачены гделибо в другом месте (например, глобальном обработчике ошибок), и очищайте ресурсы и состояние после возникновения исключения. Глобальный обработчик исключений, отображающий глобальную страницу ошибок или сообщение об ошибке, пригодится для всех необрабатываемых исключений. Как правило, необрабатываемые исключения указывают на то, что система находится в несогласованном состоянии и, возможно, требует корректного завершения.
Различайте системные исключения и ошибки бизнес-логики. Для ошибок бизнеслогики выводите на экран понятное пользователю сообщение об ошибке и предоставьте пользователю возможность повторить операцию. Для системных ошибок проведите проверку причины возникновения исключения (например, сбой сервиса или базы данных), выведите на экран понятное пользователю сообщение об ошибке и запротоколируйте сообщение об ошибке, что будет полезным при диагностике и устранении неисправностей.
Перехватывайте только те исключения, которые можете обработать, и избегайте использования собственных исключений без крайней надобности. Не применяйте исключения для управления потоком логики приложения.
Более подробно методики управления исключениями рассматриваются в главе 17, «Сквозная функциональность».
Навигация
Разрабатывайте стратегию навигации так, чтобы пользователи могли без труда перемещаться по экранам или страницам приложения, и чтобы можно было отделить функциональность навигации от формирования и обработки UI. Обеспечьте единообразное представление навигационных ссылок и элементов управления во всем приложении, чтобы не запутывать
пользователя и скрыть сложность приложения. При проектировании стратегии навигации руководствуйтесь следующими рекомендациями:
Спроектируйте панели инструментов и меню, чтобы пользователи могли находить функции, предоставляемые UI.
Обеспечьте предсказуемость реализации навигации между формами с помощью мастеров и определитесь с тем, как будете сохранять состояние навигации между сеансами в случае необходимости.
Избегайте дублирования логики для обработчиков событий навигации и по возможности не указывайте в коде пути переходов. Для обработки обычных действий из множества источников используйте шаблон Command (Команда).
Взаимодействие с пользователем
Хороший стиль взаимодействия с пользователем и пользовательский интерфейс – вот что отличает хорошее приложение от плохого. Видимая производительность имеет намного большее значение, чем фактическая, поэтому решающее значение имеют управление ожиданиями и знание типовых схем взаимодействия с пользователем. Например, возможно, пользователи не будут против немного дольше подождать загрузки страницы, если получают обратную связь со сведениями о предположительных сроках загрузки, и это ожидание не мешает продолжению их работы. В других ситуациях очень короткая задержка, для некоторых действий UI даже доли секунды, может создать ощущение, что приложение не отвечает. Изучите исследования удобства использования, опросы и интервью, чтобы понять, чего пользователи хотят и ожидают от приложения, и на основании этих сведений спроектируйте эффективный UI. При проектировании взаимодействия с пользователем руководствуйтесь следующими рекомендациями:
Не создавайте перегруженные или слишком сложные интерфейсы. Обеспечивайте четкую схему работы с приложением для всех основных сценариев пользователя, применяйте цвета и ненавязчивую анимацию для привлечения внимания пользователя к важным изменениям в UI, таким как изменение состояния.
Обеспечьте полезные и информативные сообщения об ошибках без предоставления в них конфиденциальных данных.
Избегайте блокирования пользовательского интерфейса при выполнении действий, для завершения которых может потребоваться довольно длительное время. Как минимум, обеспечьте обратную связь о ходе выполнения действия и продумайте возможность отмены операции.
Рассмотрите возможность предоставления пользователю дополнительных возможностей по конфигурированию и, где это возможно, персонализации UI, обеспечивая тем самым гибкий и настраиваемый UI.
Продумайте, как будет обеспечиваться поддержка локализации и глобализации, даже если это не является основным требованием на начальных этапах проектирования. Добавление поддержки локализации и глобализации после