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

3.Выберите технологию доступа к данным. Определитесь с тем, какая функциональность необходима для реализации логики доступа к данным, и выберите технологию, отвечающую этим требованиям. Доступные на платформе Microsoft технологии доступа к данным представлены в Приложении С, «Матрица технологий доступа к данным».

4.Спроектируйте компоненты доступа к данным. Перечислите все источники данных, которые хотите использовать, и примите решение о методе доступа для каждого из них. Примите решение о том, потребуются ли вспомогательные компоненты или желательно упростить разработку и обслуживание компонентов доступа к данным. Наконец, выберите соответствующие шаблоны проектирования. Например, рассмотрите такие шаблоны, как Table Data Gateway, Query Object, Repository и другие. Подробнее эти вопросы рассматриваются в главе 15, «Проектирование компонентов слоя доступа к данным».

5.Спроектируйте агенты сервисов. Используйте соответствующий инструмент для добавления ссылки на сервис. Это обеспечит создание прокси-классов и классов данных, которые представляют контракт данных сервиса. Затем определите, как сервис будет использоваться в приложении. В большинстве приложений доступ к функциональности и данным, предоставляемым агентами сервисов, реализуется посредством компонентов доступа к данным, что обеспечивает единый интерфейс независимо от источника данных. Для небольших приложений бизнес-слой, или даже слой представления, может работать с агентом сервиса напрямую.

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

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

Категория	Шаблоны
Общие	Active Record (Активная запись). Включает объект доступа к данным в сущность
	предметной области.
	Data Mapper (Преобразователь данных). Реализует слой преобразования между
	объектами и структурой базы данных, используемый для перемещения данных из
	одной структуры в другую, обеспечивая при этом их независимость.
	Data Transfer Object (Объект передачи данных). Объект, в котором сохраняются
	данные, передаваемые между процессами, что обеспечивает сокращение
	необходимого числа вызовов методов.
	Domain Model (Модель предметной области). Набор бизнес-объектов,
	представляющих сущности предметной области и отношения между ними.
	Query Object (Объект запроса). Объект, представляющий запрос к базе данных.
	Repository (Хранилище). Представление источника данных в памяти, работающее с
	сущностями предметной области.

Row Data Gateway (Шлюз записи данных). Объект, выступающий в роли шлюза к отдельной записи источника данных.

Table Data Gateway (Шлюз таблицы данных). Объект, выступающий в роли шлюза к таблице или представлению источника данных и выполняющий сериализацию всех запросов на выбор, вставку, обновление и удаление.

Table Module (Модуль таблицы). Единый компонент, реализующий бизнес-логику для всех строк таблицы или представления базы данных.

Пакетная Parallel Processing (Параллельная обработка). Позволяет обрабатывать множество обработка пакетных операций одновременно, чтобы сократить время обработки.

Partitioning (Секционирование). Разбивает большие пакеты, чтобы обрабатывать их параллельно.

Транзакции Capture Transaction Details (Перехват данных транзакции). Создает объекты базы данных, такие как триггеры и теневые таблицы, для записи всех изменений, вносимых в ходе транзакции.

Coarse Grained Lock (Блокировка крупных фрагментов данных). Одной блокировкой блокирует набор взаимосвязанных объектов.

Implicit Lock (Неявная блокировка). Использует код инфраструктуры для запроса блокировки от имени кода, выполняющего доступ к совместно используемым ресурсам.

Optimistic Offline Lock (Оптимистическая блокировка в автономном режиме).

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

Pessimistic Offline Lock (Пессимистическая блокировка в автономном режиме).

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

Transaction Script (Сценарий транзакции). Организует бизнес-логику каждой транзакции в одну процедуру, обращаясь к базе данных напрямую либо через тонкую оболочку над базой данных.

Более подробно шаблоны Domain Model, Table Module, Coarse-Grained Lock, Implicit Lock, Transaction Script, Active Record, Data Mapper, Data Transfer Object, Optimistic Offline Locking, Pessimistic Offline Locking, Query Object, Repository, Row Data Gateway и Table Data Gateway

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

Более подробно шаблон Capture Transaction Details рассматривается в статье «Data Patterns»

(Шаблоны данных) по адресу http://msdn.microsoft.com/en-us/library/ms998446.aspx.

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

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

«.NET Data Access Architecture Guide» (Руководство по архитектуре доступа к данным в .NET) по адресу http://msdn.microsoft.com/en-us/library/ms978510.aspx.

«Concurrency Control» (Управление параллельной обработкой) по адресу http://msdn.microsoft.com/en-us/library/ms978457.aspx.

«Data Patterns» по адресу http://msdn.microsoft.com/en-us/library/ms998446.aspx.

«Designing Data Tier Components and Passing Data Through Tiers» (Проектирование компонентов уровня доступа к данных и передача данных по уровням) по адресу http://msdn.microsoft.com/en-us/library/ms978496.aspx.

«Typing, storage, reading, and writing BLOBs» (Ввод, хранение, чтение и запись BLOB-

объектов) по адресу http://msdn.microsoft.com/enus/library/ms978510.aspx#daag_handlingblobs.

«Using stored procedures instead of SQL statements» (Использование хранимых процедур вместо SQL-выражений) по адресу http://msdn.microsoft.com/enus/library/ms978510.aspx.

Сайт сообщества «NHibernate Forge» по адресу http://nhforge.org/Default.aspx.

9

Рекомендации по проектированию слоя сервисов

Обзор

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

В слое сервисов определяется и реализуется интерфейс сервиса и контракты данных (или типы сообщений). Одним из самых важных моментов, о котором нельзя забывать, является то, что сервис никогда не должен раскрывать детали внутренних процессов или бизнес-сущностей, используемых в приложении. В частности, необходимо гарантировать, что сущности бизнесслоя не будут оказывать большого влияния на контракты данных. Слой сервисов должен предоставлять компоненты-трансляторы, которые будут обеспечивать преобразование форматов данных между сущностями бизнес-слоя и контрактами данных.

На рис. 1 показано место слоя сервисов в общей архитектуре приложения.