Somasegar S., Guthrie Scott. Руководство Microsoft по проектированию архитектуры приложений

Подождите немного. Документ загружается.

даже в случае предоставления всех известных вариантов ввода. Продумайте, как

упростить задание и понимание входных и выходных данных системы для упрощения

создания вариантов тестирования.

Взаимодействие с пользователем /удобство и простота использования

Интерфейсы приложений должны проектироваться с учетом требований пользователя и

потребителя, так чтобы они были просты в использовании, могли быть локализованы и

глобализованы, были доступны для пользователей с физическими недостатками и

обеспечивали хорошее взаимодействие с пользователем в общем. Рассмотрим основные

проблемы взаимодействия с пользователем:

 Для выполнения задачи требуется слишком много действий (и нажатий клавиш).

Обеспечивайте максимальную простоту использования при проектировании логики

работы с окнами и вводом данных, а также сценариев взаимодействия с

пользователем.

 Неверная последовательность выполнения шагов в многошаговых интерфейсах. По

возможности используйте рабочие процессы для упрощения многошаговых операций.

 Неправильная группировка элементов данных и элементов управления. Правильно

выбирайте типы элементов управления (такие как группы переключателей и кнопки-

флажки) и компонуйте элементы управления и содержимое, используя общепринятые

шаблоны проектирования UI.

 Плохая обратная связь с пользователем, особенно для ошибок и исключений, и в

случаях, когда приложение не отвечает. Реализуйте технологии и техники,

обеспечивающие максимальное взаимодействие с пользователем, такие как

Asynchronous JavaScript and XML (AJAX)

на Веб-страницах и проверка ввода на стороне

клиента. Для фоновых задач и таких задач, как заполнение элементов управления

данными или выполнение длительных задач, применяйте асинхронные методики.

Дополнительные источники

Электронная версия списка используемых источников по реализации и аудиту показателей

качества доступна по адресу http://www.microsoft.com/architectureguide.

 «Implementing System-Quality Attributes» (Реализация показателей качества системы)

по адресу http://msdn.microsoft.com/en-us/library/bb402962.aspx.

 «Software Architecture in the New Economy» (Архитектура ПО в новых экономических

условиях) по адресу http://msdn.microsoft.com/en-us/library/cc168642.aspx.

 «Quality-Attribute Auditing: The What, Why, and How» (Аудит показателей качества: что,

как и почему) по адресу http://msdn.microsoft.com/en-us/library/bb508961.aspx.

 Майкл К. Физерс. Эффективная работа с унаследованным кодом. Вильямс, 2009.

Асинхронный JavaScript и XML (прим. переводчика).

 Кайл Бейли (Kyle Baley) и Дональд Белчам (Donald Belcham). Brownfield Application

Development in .NET (Разработка приложений Brownfield в .NET). Manning Publications

Co, 2008.

 Майкл Найгард (Michael Nygard). Release It!: Design and Deploy Production-Ready

Software (Проектирование и развертывание готового к производственной

эксплуатации ПО). Pragmatic Bookshelf, 2007.

Сквозная функциональность

Обзор

В большинстве проектируемых приложений имеется общая функциональность, которую

нельзя отнести к конкретному слою или уровню. Обычно это такие операции как

аутентификация, авторизация, кэширование, связь, управление исключениями,

протоколирование и инструментирование, а также валидация. Эти функции называют

сквозной функциональностью (crosscutting concerns), потому что они оказывают влияние на

все приложение и, по возможности, должны реализовываться централизованно. Например,

если код, формирующий записи журнала и выполняющий запись в журналы приложения,

разбросан по разным слоям и уровням, в случае изменения требований, связанных с этими

вопросами (например, перенесение журнала в другой каталог), придется выискивать и

обновлять соответствующий код по всему приложению. Но если код протоколирования

централизован, изменить поведение, можно изменив код лишь в одном месте.

Данная глава поможет понять роль сквозной функциональности в приложении и найти

области, в которых эта функциональность используется. В ней также представлены основные

проблемы, с которыми придется столкнуться при проектировании сквозной

функциональности. Существует несколько разных подходов к реализации этой

функциональности, начиная от общих библиотек, таких как Enterprise Library группы patterns &

practices, до методов аспектно-ориентированного программирования (Aspect Oriented

Programming, AOP), использующих метаданные для внедрения кода сквозной

функциональности непосредственно в откомпилированный вывод или во время выполнения.

Общие принципы проектирования

Следующие рекомендации помогут понять основные факторы, оказывающие влияние на

сквозную функциональность:

 Проанализируйте все функции в каждом слое и найдите те из них, которые могут

быть выделены в общие компоненты, возможно, даже компоненты общего

назначения, настраиваемые в зависимости от конкретных требований каждого слоя

приложения. Скорее всего, эти компоненты можно будет использовать и в других

приложениях.

 В зависимости от физического распределения компонентов и слоев приложения,

возможно, понадобится установить компоненты сквозной функциональности на

нескольких физических уровнях. Но несмотря на это, преимущества от возможности

повторного использования и сокращения времени и затрат на разработку

сохраняются.

 Используйте шаблон Dependency Injection для внедрения экземпляров

компонентов сквозной функциональности в приложение на основании данных

конфигурации. Это позволяет без труда изменять используемые в каждой

подсистеме компоненты сквозной функциональности без необходимости

повторной компиляции и развертывания приложения. Библиотека Unity группы

patterns & practices обеспечивает полную поддержку шаблона Dependency Injection.

К другим популярным библиотекам Dependency Injection относятся StructureMap,

Ninject и Castle Windsor (больше информации по этому вопросу можно найти в

разделе Дополнительные источники в конце данной главы).

 Сократить время разработки позволит использование библиотек компонентов

сторонних производителей, предоставляющих легкоконфигурируемые компоненты.

Одним из примеров такой библиотеки является Enterprise Library группы patterns &

practices, содержащая блоки приложений, которые облегчат реализацию функций

кэширования, обработки исключений, аутентификации и авторизации,

протоколирования, валидации и шифрования. Она также включает механизмы,

реализующие контейнер внедрения политик и зависимостей, которые упрощают

реализацию решений для ряда аспектов сквозной функциональности. Более

подробно Enterprise Library рассматривается в приложении F, «Enterprise Library от

patterns & practices». Другой популярной библиотекой является Castle Project

(больше информации по этому вопросу можно найти в разделе Дополнительные

источники в конце данной главы).

 Используйте методики аспектно-ориентированного программирования (AOP), что

поможет внедрить сквозную функциональность в приложение без реализации

явных вызовов в коде. Библиотека Unity и Enterprise Library Policy Injection

Application Block (Блок внедрения политик библиотеки Enterprise Library) группы

patterns & practices поддерживают этот подход. Другими примерами являются

библиотеки Castle Windsor и PostSharp (больше информации по этому вопросу

можно найти в разделе Дополнительные источники в конце данной главы).

Специальные вопросы проектирования

В следующих разделах перечислены основные области, которые следует рассмотреть при

разработке архитектуры, и приведены рекомендации, которые помогут избежать обычных

проблем в каждой из этих областей:

 Аутентификация

 Авторизация

 Кэширование

 Сетевое взаимодействие

 Управление конфигурацией

 Управление исключениями

 Протоколирование и инструментирование

 Управление состоянием

 Валидация

Аутентификация

Проектирование эффективной стратегии аутентификации имеет большое значение с точки

зрения обеспечения безопасности и надежности приложения, в противном случае, оно будет

уязвимым для атак с подделкой пакетов, атак перебором по словарю, перехватом сеансов и

других типов атак. При проектировании стратегии аутентификации руководствуйтесь

следующими рекомендациями:

 Определите границы доверия и проводите аутентификацию пользователей и

вызовов на границах доверия. Учтите, что может понадобиться аутентифицировать

вызовы, как клиента, так и сервера (взаимная аутентификация).

 Обеспечьте использование надежных паролей или парольных фраз.

 При наличии множества систем в рамках приложения, или если пользователи

должны иметь возможность доступа ко многим приложениям, используя одни и те

же учетные данные, применяйте стратегию единой регистрации.

 Не передавайте пароли по сети и не храните их в базе данных или хранилище

данных в открытом виде. Храните хеш пароля.

Больше сведений о разработке стратегии аутентификации и методиках ее реализации можно

найти в разделе «Дополнительные источники» в конце данной главы.

Авторизация

Проектирование эффективной стратегии авторизации имеет большое значение с точки зрения

обеспечения безопасности и надежности приложения, в противном случае, оно будет

уязвимым для разглашения сведений, повреждения или подделки данных и

несанкционированного получения прав. При проектировании стратегии авторизации

руководствуйтесь следующими рекомендациями:

 Определите границы доверия и проводите авторизацию пользователей и вызовов

на границах доверия.

 Защитите ресурсы, проводя авторизацию вызывающей стороны на основании ее

удостоверения, групп или ролей. Обеспечьте минимальное дробление, по

возможности ограничивая количество используемых ролей.

 Применяйте авторизацию на основании ролей для бизнес-решений. При

авторизации на основании ролей все пользователи распределяются по группам

(ролям), что позволяет задавать права доступа для роли, а не для каждого

пользователя в отдельности. Это упрощает управление, поскольку администратору

приходится работать лишь с небольшим набором ролей, а не со всеми

пользователями системы.

 Применяйте авторизацию на базе ресурсов для аудита системы. При авторизации

на базе ресурсов права доступа определяются в самом ресурсе. Например, список

управления доступом (ACL) ресурса Windows использует удостоверение исходного

вызывающего для определения его прав доступа к ресурсу. При использовании

авторизации на базе ресурсов в WCF необходимо выполнить олицетворение

исходного вызывающего через клиента или слой представления, через слой

сервисов WCF и для кода бизнес-логики, выполняющего доступ к ресурсу.

 Используйте авторизацию на основании утверждений, если требуется

поддерживать интегрированную авторизацию на базе сочетания данных, таких как

удостоверение, роль, разрешения, права и т.д. Авторизация на основании

утверждений обеспечивает дополнительные уровни абстракции, что упрощает

отделение правил авторизации от механизма авторизации и аутентификации.

Например, пользователь может быть аутентифицирован по сертификату или имени

пользователя/паролю, после чего набор этих утверждений передается в сервис для

определения прав доступа к ресурсу.

Больше сведений о разработке стратегии авторизации и методиках ее реализации можно

найти в разделе «Дополнительные источники» в конце данной главы.

Кэширование

Кэширование может улучшить производительность и время отклика приложения. Однако

неправильно спроектированная стратегия кэширования может негативно сказаться на этих

показателях. Кэширование должно применяться для оптимизации поиска используемых

данных, сокращения количества обращений к сети и предотвращения ненужной или

повторной обработки. При реализации кэширования необходимо принять решение о том,

когда загружать кэшированные данные, а также как и когда удалять устаревшие

кэшированные данные. Предварительная асинхронная загрузка в кэш часто используемых

данных или применение пакетной обработки помогут избежать задержек на стороне клиента.

При проектировании стратегии кэширования руководствуйтесь следующими

рекомендациями:

 Выберите подходящее размещение для кэша. Если приложение развертывается на

Веб-ферме, избегайте применения локальных кэшей, для которых необходима

синхронизация. В этом случае рекомендуется использовать систему управления

транзакционными ресурсами, такую как Microsoft® SQL Server®, или продукт,

поддерживающий распределенное кэширование, такой как технология Memcached

производства компании Danga Interactive или механизм кэширования Velocity от

компании Microsoft (больше информации по этому вопросу можно найти в разделе

Дополнительные источники в конце данной главы).

 При работе с кэшем в памяти применяйте кэширование данных в готовом к

использованию виде. Например, кэшируйте не просто необработанные данные

базы данных, а используйте специализированные объекты необходимые

приложению. Реализуйте кэширование в памяти с помощью Microsoft Velocity.

 Не кэшируйте часто изменяющиеся данные и незашифрованные

конфиденциальные данные.

 Не полагайтесь на кэшированные данные, они могут быть удалены. Реализуйте

механизм обработки сбоев кэша, возможно, путем повторной загрузки элемента из

источника.

 Будьте особенно осторожны при работе с кэшем из нескольких потоков. В случае

использования множества потоков для обеспечения непротиворечивости данных

убедитесь, что любой доступ к кэшу является потокобезопасным.

Более подробно разработка стратегии кэширования рассматривается в разделе «Этапы

проектирования стратегии кэширования» далее в этой главе.

Сетевое взаимодействие

Средства связи обеспечивают взаимодействие компонентов разных слоев и уровней. Выбор

механизма связи зависит от сценариев развертывания, которые должно поддерживать ваше

приложение. При проектировании стратегии связи руководствуйтесь следующими

рекомендациями

 Используйте взаимодействие посредством обмена сообщениями при пересечении

физических границ или границ процесса; и взаимодействие объектов внутри

процесса (при пересечении только логических границ). Для сокращения числа

циклов запрос-ответ и повышения производительности взаимодействия через

физические границы и границы процесса, проектируйте обобщенные интерфейсы,

взаимодействующие не так часто, но передающие большие объемы данных при

каждом взаимодействии. Тем не мене, там где это необходимо, предоставляйте

детализированные интерфейсы, которые будут использоваться вызовами внутри

процесса, и заключайте эти вызовы в обобщенный фасад, который будет

использоваться процессами, выполняющими доступ к нему через физические

границы или границы процессов.

 Если порядок получения сообщений не имеет значения, и сообщения не зависят

друг от друга, используйте асинхронное взаимодействие. Это поможет избежать

блокировки обработки или потоков UI.

 Используйте механизм Microsoft Message Queuing, обеспечивающий помещение

сообщений в очередь для их отложенной доставки в случае сбоя системы или

разрыва подключения. Message Queuing может осуществлять транзакционную

доставку сообщений и поддерживает гарантированную одноразовую доставку.

 Выбирайте соответствующий транспортный протокол, такой как HTTP для связи

через Интернет и TCP для связи по внутренней сети. Продумайте соответствующие

схемы обмена сообщениями, то, будете ли вы использовать взаимодействие с

установлением подключения или без установления подключения, поддержку

гарантий надежности (такие как соглашения на уровне сервиса) и механизм

аутентификации.

 Обеспечьте защиту сообщений и конфиденциальных данных при передаче,

используя шифрование, цифровые сертификаты и функции безопасности каналов.

Более подробно проектирование стратегии взаимодействия рассматривается в главе 18,

«Взаимодействие и обмен сообщениями».

Управление конфигурацией

Правильный выбор механизма управления конфигурацией имеет большое значение с точки

зрения обеспечения безопасности и надежности приложения, в противном случае, оно будет

уязвимым для различных атак. Также неправильный механизм управления конфигурацией

может обусловливать издержки на администрирование приложения. При проектировании

стратегии управления конфигурацией руководствуйтесь следующими рекомендациями:

 Тщательно продумывайте, какие параметры должны быть конфигурируемыми

извне. Убедитесь в реальной прикладной целесообразности каждого

настраиваемого параметра и обеспечьте минимум параметров конфигурации,

необходимый для выполнения этих требований. Излишняя настраиваемость может

усложнить систему и сделать ее уязвимой из-за брешей безопасности и

неправильного функционирования, обусловленных неверной конфигурацией.

 Примите решение о том, будут ли сведения о конфигурации храниться

централизованно и загружаться или применяться к пользователям при запуске

(например, через Active Directory Group Policy

). Продумайте, как обеспечите

ограничение доступа к сведениям о конфигурации. Используйте менее

привилегированный процесс и учетные записи сервиса и шифруйте

конфиденциальные данные в хранилище конфигурации.

 Распределите элементы конфигурации по логическим разделам на основании того,

являются ли они настройками пользователя, приложения или среды. Это упростит

разделение конфигурации, если потребуется поддерживать разные настройки для

разных наборов пользователей или множества сред.

 При наличии множества уровней в приложении распределите элементы

конфигурации по логическим разделам. Если сервер приложений выполняется на

Веб-ферме, определите, какая часть конфигурации является общей, и какая часть

применяется исключительно к компьютеру, на котором выполняется приложение.

После этого выберите соответствующее хранилище конфигурации для каждого

раздела.

 Предоставьте отдельный административный UI для редактирования

конфигурационных данных.

Групповая политика Active Directory (прим. переводчика).

Управление исключениями

Проектирование эффективной стратегии управления исключениями имеет большое значение с

точки зрения обеспечения безопасности и надежности приложения. Неправильный выбор

стратегии очень усложнит диагностирование и решение проблем приложения, сделает его

уязвимым для атак типа отказ в обслуживании (DoS), а также может привести к разглашению

конфиденциальных и важных сведений. Формирование и обработка исключений является

ресурсоемким процессом, поэтому важно, чтобы при проектировании были также учтены

вопросы производительности. Хорошим подходом является проектирование

централизованного механизма управления исключениями для приложения и предоставление

точек доступа к системе управления исключениями (таких как события WMI) для обеспечения

поддержки систем мониторинга уровня предприятия, таких как Microsoft System Center. При

проектировании стратегии управления исключениями руководствуйтесь следующими

рекомендациями:

 Проектируйте соответствующую стратегию распространения исключений, которая

обеспечивает обертывание или замену исключений или внесение необходимых

дополнительных данных. Например, позвольте исключениям распространяться

вверх к граничным слоям, где они могут быть запротоколированы и преобразованы

должным образом для передачи в следующий слой. Применяйте контекстные

идентификаторы, это позволит находить взаимосвязанные исключения в разных

слоях при проведении анализа основных причин ошибок и сбоев. Также убедитесь,

что в дизайне предусмотрены необрабатываемые исключения. Перехватывайте

внутренние исключения, только если можете обработать их или должны добавить

некоторые данные. Не используйте исключения для управления логикой

приложения.

 Обеспечьте, чтобы приложение не оставалось в нестабильном состоянии после

сбоя, и чтобы исключения не приводили к разглашению конфиденциальных данных

или сведений о процессе. Если не можете гарантированно обеспечить корректное

восстановление после сбоя, позвольте приложению завершиться с

необработанным исключением; это лучше, чем оно будет продолжать выполнение

в неизвестном и, возможно, поврежденном состоянии.

 Выработайте соответствующую стратегию протоколирования и уведомления для

критических ошибок и исключений, обеспечивая сохранение достаточно детальных

сведений об исключении. Это позволит техническому персоналу восстановить

сценарий, который привел к исключению. Однако не предоставляйте

конфиденциальные данные в сообщениях об исключениях и файлах журнала.

Более подробно проектирование стратегии управления исключениями рассматривается в

разделе «Этапы проектирования стратегии управления исключениями» далее в этой главе.

Протоколирование и инструментирование

Проектирование эффективной стратегии протоколирования и инструментирования имеет

большое значение с точки зрения обеспечения безопасности и надежности приложения, в

противном случае, пользователи смогут безнаказанно отказываться от своих действий. Также

файлы журналов могут пригодиться для доказательства правонарушений в случае судебного

разбирательства. Аудит и протоколирование действий во всех слоях приложения необходимы,

потому что могут помочь обнаружить подозрительные действия и обеспечить раннее

выявление серьезных атак. Аудит считается наиболее достоверным, если данные аудита

формируются непосредственно в момент доступа к ресурсу и именно теми процедурами,

которые выполняют доступ к ресурсу. Инструментирование можно реализовать, используя

счетчики производительности и события, обеспечивающие администраторов сведениями о

состоянии, производительности и работоспособности приложения. При проектировании

стратегии протоколирования и инструментирования руководствуйтесь следующими

рекомендациями:

 Проектируйте централизованный механизм протоколирования и

инструментирования, обеспечивающий перехват критически важных для системы и

бизнеса событий. Избегайте слишком детализированного протоколирования и

инструментирования, но предусмотрите дополнительные функции

протоколирования и инструментирования, настраиваемые во время выполнения,

для получения дополнительных данных и для помощи при отладке.

 Создавайте политики безопасного управления файлами журнала. Не храните

конфиденциальные данные в файлах журнала и защищайте их от

неавторизованного доступа. Продумайте, как обеспечить безопасный доступ и

передачу данных аудита и протоколирования между слоями приложения, и

обеспечьте сдерживание и правильную обработку сбоев протоколирования.

 Сделайте свои приемники журнала, или слушатели трассировки, настраиваемыми,

чтобы обеспечить возможность их изменения во время выполнения соответственно

требованиям инфраструктуры развертывания. В реализации протоколирования и

инструментирования в приложении очень помогут такие библиотеки, как Enterprise

Library группы patterns & practices. Среди популярных библиотек можно также

упомянуть NLog и log4net (больше информации по этому вопросу можно найти в

разделе Дополнительные источники в конце данной главы)

Более подробно протоколирование и инструментирование рассматриваются в разделе «Этапы

проектирования стратегии управления исключениями» далее в этой главе.

Управление состоянием

Управление состоянием – это вопросы, связанные с хранением данных, представляющих

состояние компонента, операции или этапа процесса. Для хранения данных состояния могут

использоваться разные форматы и хранилища. Механизм управления состоянием может

оказывать влияние на производительность приложения; сохранение даже небольших объемов

данных состояния может неблагоприятно сказываться на производительности приложения и

его способности масштабироваться. Сохраняться должны только необходимые данные, и вы

должны понимать, какие варианты управления состоянием допустимы. При проектировании

стратегии управления состоянием руководствуйтесь следующими рекомендациями:

 Сохраняйте минимальный объем данных состояния.