Шаблоны проектирования

Основные шаблоны для компонентов организованы по категориям и представлены в следующей таблице. Рассмотрите возможности применения этих шаблонов при принятии проектных решений для каждой из категорий.

Категория	Шаблоны проектирования
Бизнес-компоненты	Application Façade (Фасад приложения). Централизует и агрегирует
	поведение для обеспечения унифицированного слоя сервисов.
	Chain of Responsibility (Цепочка обязанностей). Предоставляя
	возможность обработать запрос нескольким объектам, устраняет
	возможность связывания отправителя запроса с его получателем.
	Command (Команда). Инкапсулирует обработку запроса в отдельный
	командный объект с общим интерфейсом выполнения.
Бизнес-сущности	Domain Model (Модель предметной области). Набор бизнес-объектов,
	представляющих сущности предметной области и отношения между
	ними.
	Entity Translator (Транслятор сущностей). Объект, преобразующий
	типы данных сообщения в бизнес-типы для запросов и выполняющий
	обратные преобразования для ответов.
	Table Module (Модуль таблицы). Единый компонент, реализующий
	бизнес-логику для всех строк таблицы или представления базы данных.
Сущности	Entity Translator (Транслятор сущностей). Объект, преобразующий
представления	типы данных сообщения в бизнес-типы для запросов и выполняющий
	обратные преобразования для ответов.
Логика представления	Application Controller (Контроллер приложений). Реализует
	централизованную точку обработки навигации по экрану и потока
	приложения.
	Model-View-Controller (Модель-Представление-Контроллер).
	Разделяет код UI на три модуля: Модель (данные), Представление
	(интерфейс) и Контроллер (логика обработки), уделяя основное
	внимание Представлению. Существует две разновидности этого
	шаблона: Passive View (Пассивное представление) и Supervising
	Presenter (Наблюдающий презентатор), которые определяют
	взаимодействие Представления с Моделью.
	Model-View-ViewModel (Модель-Представление-Модель
	представления). Разновидность шаблона MVC, в которой
	взаимодействие Представления и Модели представления реализуются с
	помощью шаблона Command.
	Model-View-Presenter (Модель-Представление-Презентатор).
	Разделяет обработку запроса на три отдельные роли, при этом
	Представление отвечает за обработку пользовательского ввода и
	передачу управления объекту Презентатора.
	Passive View (Пассивное представление). Сокращает представление
	до необходимого минимума, перенося в контроллер функциональность
	обработки пользовательского ввода и реализацию обновления
	представления.
	Presentation Model (Модель презентации). Выносит всю логику
	представления и состояние из представления и реализует

	формирование визуального представления через связывание данных и
	шаблоны.
	Supervising Presenter (или Supervising Controller) (Наблюдающий
	презентатор или Наблюдающий контроллер). Разновидность шаблона
	MVC, где контроллер отвечает за обработку сложной логики, в частности,
	согласование представлений, а представление отвечает за простую
	логику, касающуюся представления.
Интерфейс сервиса	Façade (Фасад). Реализует унифицированный интерфейс для набора
	операций, чтобы обеспечить упрощенный интерфейс и уменьшить
	связанность систем.
	Remote Façade (Удаленный фасад). Создает обобщенный
	унифицированный интерфейс для набора операций или процессов в
	удаленной подсистеме, обеспечивая слабо детализированный
	интерфейс для детализированных операций, чтобы упростить
	использование этой подсистемы и свести до минимума вызовы по сети.
	Service Interface (Интерфейс сервиса). Программный интерфейс,
	который может использоваться другими системами для взаимодействия
	с сервисом.
Рабочие процессы	Data-Driven Workflow (Управляемый данными рабочий процесс).
	Рабочий процесс, включающий задачи, последовательность выполнения
	которых определяется значениями данных в рабочем процессе или
	системе.
	Human Workflow (Рабочий процесс оператора). Рабочий процесс,
	включающий задачи, выполняемые вручную.
	Sequential Workflow (Последовательный рабочий процесс). Рабочий
	процесс, включающий задачи, выполняющиеся в определенной
	последовательности, когда выполнение одной задачи запускается только
	после завершения предыдущей.
	State-Driven Workflow (Управляемый состоянием рабочий процесс).
	Рабочий процесс, включающий задачи, последовательность выполнения
	которых определяется состоянием системы.

Более подробно шаблон Façade рассматривается в главе 4, «Структурные шаблоны», книги Эрика Гамма, Ричарда Хельма, Ральфа Джонсона и Джона Влиссидса «Приемы объектно-

ориентированного проектирования. Паттерны проектирования». Питер, 2006.

Более подробно шаблон Chain of Responsibility рассматривается в статье «Patterns in Practice»

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

Более подробно шаблон Command рассматривается в главе 5, «Поведенческие шаблоны», книги Эрика Гамма, Ричарда Хельма, Ральфа Джонсона и Джона Влиссидса « Приемы объектно-ориентированного проектирования. Паттерны проектирования ». Питер, 2006.

Более подробно шаблон Entity Translator рассматривается в статье «Useful Patterns for Services»

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

Более подробно шаблоны Data-Driven Workflow, Human Workflow, Sequential Workflow и StateDriven Workflow рассматриваются в статье «Windows Workflow Foundation Overview» (Обзор

Windows Workflow Foundation) по адресу http://msdn.microsoft.com/enus/library/ms734631.aspx и "Workflow Patterns" по адресу http://www.workflowpatterns.com/.

Более подробно шаблоны Application Controller и Model-View-Controller (MVC)

рассматриваются в книге Мартина Фаулера «Архитектура корпоративных программных приложений». Вильямс, 2007. Или по адресу http://martinfowler.com/eaaCatalog.

Более подробно шаблоны Supervising Presenter и Presentation Model рассматриваются в статье

«Patterns in the Composite Application Library» по адресу http://msdn.microsoft.com/enus/library/dd458924.aspx.

Более подробно шаблон Remote Façade рассматривается в статье «P of EAA: Remote Façade» по адресу http://martinfowler.com/eaaCatalog/remoteFacade.html.

Предложения группы patterns & practices

Узнать о дополнительных предложениях группы Microsoft patterns & practices можно из следующих источников:

«Composite Client Application Guidance» по адресу http://msdn.microsoft.com/enus/library/cc707819.aspx.

«Enterprise Library» по адресу http://msdn.microsoft.com/en-us/library/cc467894.aspx.

«Smart Client Software Factory» по адресу http://msdn.microsoft.com/enus/library/aa480482.aspx.

«Unity» (механизм внесения зависимостей) по адресу http://msdn.microsoft.com/enus/library/dd203101.aspx.

«Web Client Software Factory» по адресу http://msdn.microsoft.com/enus/library/bb264518.aspx.

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

Электронная версия списка используемых источников доступна по адресу http://www.microsoft.com/architectureguide.

«Integration Patterns» по адресу http://msdn.microsoft.com/enus/library/ms978729.aspx.

Martin, Robert C. and Micah Martin. Agile Principles, Patterns, and Practices in C#.

Prentice Hall, 2006.

«User Interface Control Guidelines» по адресу http://msdn.microsoft.com/enus/library/bb158625.aspx.

11

Проектирование компонентов представления

Обзор

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

Прежде всего, требуется понять, какие требования предъявляются к UI, и суметь выбрать соответствующую технологию. После этого уже можно принимать решения о связывании логики представления и данных с элементами управления UI. Также необходимо иметь четкое представление о требованиях к обработке ошибок и проверке в UI. В следующих разделах этой главы более подробно рассматриваются шаги по проектированию компонентов представления.

Шаг 1 – Понимание предъявляемых к UI требований

Понимание предъявляемых к UI требований – ключ к принятию решений по типу UI, технологии и типу элементов управления, используемым для его реализации. Требования к UI определяются функциональностью, которую должно поддерживать приложение, и ожиданиями пользователей.

Начните с выяснения, кто будет пользователями приложения, и понимания целей и задачей, которые эти пользователи желают реализовывать при использовании приложения. Особое внимание уделите вопросу последовательности задач или операций; выясните, ожидают ли пользователи структурированного последовательного взаимодействия или неструктурированного взаимодействия с произвольным порядком операций, когда существует возможность выполнения множества задач одновременно. Как часть этого процесса, также выясните, какие данные понадобятся пользователям, и формат, в котором они ожидают их увидеть. Возможно, придется провести исследования, чтобы лучше понять среду, в которой пользователь будет взаимодействовать с приложением. Кроме того, рассмотрите текущие уровни взаимодействия с пользователем и сравните их с требованиями к взаимодействию с пользователем, предъявляемыми для разрабатываемого UI, чтобы убедиться в их логичности и понятности. Все эти факторы помогут создать ориентированный на пользователя дизайн.