17

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

Обзор

В большинстве проектируемых приложений имеется общая функциональность, которую нельзя отнести к конкретному слою или уровню. Обычно это такие операции как аутентификация, авторизация, кэширование, связь, управление исключениями, протоколирование и инструментирование, а также валидация. Эти функции называют сквозной функциональностью (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 (больше информации по этому вопросу можно найти в разделе Дополнительные источники в конце данной главы).

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