Более подробно шаблоны Data Confidentiality и Data Origin Authentication рассматриваются в материале «Chapter 2: Message Protection Patterns» (Глава 2: Механизмы защиты сообщений)
по адресу http://msdn.microsoft.com/en-us/library/aa480573.aspx.
Более подробно шаблоны Replay Detection, Exception Shielding и Validation рассматриваются в материале «Chapter 5: Service Boundary Protection Patterns» (Глава 5: Механизмы защиты границ сервиса) по адресу http://msdn.microsoft.com/en-us/library/aa480597.aspx.
Более подробно шаблоны Claim Check, Content Enricher, Content Filter и Envelope Wrapper
рассматриваются в материале «Messaging Patterns in Service Oriented Architecture, Part 2» по адресу http://msdn.microsoft.com/en-us/library/aa480061.aspx.
Более подробно шаблон Remote Façade рассматриваются в статье «Patterns of Enterprise Application Architecture: Remote Façade» (Архитектура корпоративных программных приложений) по адресу http://martinfowler.com/eaaCatalog/remoteFacade.html.
Более подробно шаблоны REST, такие как Behavior, Container и Entity, рассматриваются в статье «REST Patterns» (Шаблоны REST) по адресу http://wiki.developer.mindtouch.com/REST/REST_Patterns.
Более подробно шаблоны Aggregator, Content-Based Router, Publish-Subscribe, Message Bus и Point-to-Point рассматриваются в материале «Messaging patterns in Service-Oriented Architecture, Part I» по адресу http://msdn.microsoft.com/en-us/library/aa480027.aspx.
Дополнительные источники
Электронная версия списка используемых источников доступна по адресу http://www.microsoft.com/architectureguide.
«Enterprise Solution Patterns Using Microsoft .NET» по адресу http://msdn.microsoft.com/en-us/library/ms998469.aspx.
«Web Service Security Guidance» (Руководство по безопасности Веб-сервисов) по адресу http://msdn.microsoft.com/en-us/library/aa480545.aspx.
«Improving Web Services Security: Scenarios and Implementation Guidance for WCF» по адресу http://www.codeplex.com/WCFSecurityGuide.
«WS-* Specifications» (Спецификации WS-*) по адресу http://www.ws- standards.com/ws-atomictransaction.asp.
10
Рекомендации по проектированию компонентов
Обзор
Компоненты являются средством изоляции определенных наборов функций в элементах, которые могут распространяться и устанавливаться отдельно от другой функциональности. Данная глава содержит общие рекомендации по созданию компонентов и описывает типы компонентов, обычно применяемые в слоях приложений, проектируемых с использованием многослойного подхода, обсуждаемого в этом руководстве. Хотя, методики построения компонентов обычно не зависят от структуры приложения.
Общие рекомендации по проектированию компонентов
Рассмотрим общие рекомендации проектирования компонентов приложений:
Применяйте принципы SOLID при проектировании классов, входящих в компонент. Принципы SOLID – это:
◦Принцип единственности ответственности (Single responsibility). Класс должен отвечать только за один аспект.
◦Принцип открытости/закрытости (Open/closed principle). Классы должны быть расширяемыми без необходимости доработки.
◦Принцип замещения Лискова (Liskov substitution principle). Подтипы и базовые типы должны быть взаимозаменяемы.
◦Принцип отделения интерфейса (Interface segregation principle). Интерфейсы классов должны быть клиент-специфическими и узконаправленными. Классы должны предоставлять разные интерфейсы для клиентов, имеющих разные требования к интерфейсам.
◦Принцип инверсии зависимостей (Dependency inversion principle).
Зависимости между классами должны заменяться абстракциями, что обеспечит возможность проектирования сверху вниз без необходимости проектирования сначала модулей нижнего уровня. Абстракции не должны зависеть от деталей – детали должны зависеть от абстракций.
Проектируйте сильно связные компоненты. Не перегружайте компоненты введением в них невзаимосвязанной или смешанной функциональности. Например, всегда избегайте смешения в компонентах бизнес-слоя логики доступа к данным и бизнес-логики. Обеспечив связность функциональности, можно создавать сборки, включающие более одного компонента, и устанавливать компоненты в соответствующих слоях приложения, даже если эти слои разделены физически.
Компонент не должен зависеть от внутренних деталей других компонентов.
Каждый компонент или объект должен вызывать метод другого объекта или компонента, и этот метод должен знать, как обрабатывать запрос и, если необходимо, как направить его к соответствующим подкомпонентам или другим компонентам. Такой подход позволяет создавать более адаптируемые и удобные в обслуживании приложения.
Продумайте, как компоненты будут взаимодействовать друг с другом. Для этого требуется понимать, какие сценарии развертывания должно поддерживать создаваемое приложение, должно ли оно поддерживать взаимодействие через физические границы или границы процесса, либо все компоненты будут выполняться в одном процессе.
Не смешивайте код сквозной функциональности и прикладную логику приложения. Код, реализующий сквозную функциональность – это код, связанный с безопасностью, связью или управлением, таким как протоколированием и инструментированием. Смешение кода, реализующего эти функции, с логикой компонентов может привести к созданию плохо расширяемого и сложного в обслуживании дизайна.
Применяйте основные принципы компонентного архитектурного стиля. Эти принципы состоят в том, что компоненты должны быть пригодными для повторного использования, заменяемыми, расширяемыми, инкапсулированными, независимыми и не зависеть от контекста. Компонентный архитектурный стиль рассматривается в главе 3, «Архитектурные шаблоны и стили».
Распределение компонентов по слоям
Каждый слой приложения содержит наборы компонентов, реализующих функциональность данного слоя. Эти компоненты должны быть связными и слабо связанными, чтобы обеспечить возможность повторного использования и упростить обслуживание. На рис. 1 показано, какие типы компонентов обычно используются в каждом из слоев.
Рис. 1
Типы компонентов, обычно используемые в каждом из слоев
Следующие разделы посвящены рассмотрению компонентов, представленных на рис. 1.
Компоненты слоя представления
Компоненты слоя представления реализуют функциональность, необходимую для обеспечения взаимодействия пользователей с приложением. Обычно в слое представления располагаются следующие типы компонентов:
Компоненты пользовательского интерфейса. Конкретная реализация пользовательского интерфейса приложения инкапсулирована в компоненты пользовательского интерфейса (UI). Это визуальные элементы приложения, используемые для отображения данных пользователю и приема пользовательского ввода. Компоненты UI, спроектированные для реализации шаблона Separated Presentation, иногда называют Представлениями (Views). В большинстве случаев их роль заключается в предоставлении пользователю интерфейса, который обеспечивает наиболее соответствующее представление данных и логики приложения, а также в интерпретации пользовательского ввода и передаче его в компоненты логики представления, которые определяют влияние ввода на данные и состояние приложения. В некоторых случаях в компонентах пользовательского интерфейса может содержаться специальная логика реализации пользовательского