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

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

данных или хранилища данных. Поймите свои границы доверия и проверяйте все данные,

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

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

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

сторон. Гарантируйте правильную обработку значений NULL и фильтрацию

недействительных символов.

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

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

SQL, должен проверяться на наличие символов или шаблонов, встречающихся в

атаках внедрением SQL-кода.

 Возвращайте информативные сообщения об ошибках в случае сбоя валидации.

Более подробно методики проверки рассматриваются в главе 17, «Сквозная

функциональность».

XML

Расширяемый язык разметки (Extensible Markup Language, XML) обеспечивает возможность

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

производительности будьте осторожны с применением XML для очень больших объемов

данных. Если требуется обрабатывать большие объемы данных в виде XML, применяйте не

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

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

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

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

 Для доступа к форматированным XML-данным используйте легковесные методы

чтения и записи XML

, особенно для очень больших наборов XML-данных. Если

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

которые поддерживают эту функциональность, такие как DataSet ADO.NET. При

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

комментариев.

 Рассмотрите возможность применения схемы XML для описания форматов и

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

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

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

 Храните XML в типизированных столбцах базы данных, если таковые имеются. Это

обеспечит максимальную производительность. Если предполагается, что XML-

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

данных их поддерживает).

То есть, не используйте XML DOM без крайней необходимости (прим. научного редактора).

Вопросы выбора технологий

Следующие рекомендации помогут правильно выбрать технологию и методики для

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

требований:

 Если требуется обеспечить поддержку запросов и параметров, используйте объекты

ADO.NET напрямую.

 Если требуется поддерживать более сложные сценарии доступа к данным или

упростить код доступа к данным, используйте Data Access Application Block (Блок

доступа к данным) библиотеки Enterprise Library. Более подробно Enterprise Library

рассматривается в приложении F, «Enterprise Library от patterns & practices».

 При создании управляемого данными Веб-приложения, страницы которого

используют модель данных базовой базы данных, используйте технологию ASP.NET

Dynamic Data (Динамические данные ASP.NET).

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

пространства имен System.Xml и его дочерних пространств имен или Linq to XML

(XLinq).

 При создании пользовательского интерфейса с помощью ASP.NET рассмотрите

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

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

Объекты DataReader идеально подходят для ситуаций, где необходимо только

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

быстро.

 Для реализации доступа к SQL Server используйте классы пространства имен

SqlClient ADO.NET, они обеспечат максимальную производительность.

 Для реализации доступа к SQL Server 2008 используйте FILESTREAM, что обеспечит

большую гибкость для хранения и доступа к BLOB-данным.

 При проектировании объектно-ориентированного бизнес-слоя на основании

шаблона Domain Model используйте O/RM-средства, такие как ADO.NET Entity

Framework или инструментарий с открытым исходным кодом NHibernate (для

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

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

Руководство по выбору технологии доступа к данным приведено в главе 15, «Проектирование

компонентов слоя доступа к данным». Технологии, доступные на платформе Microsoft,

представлены в приложении С, «Матрица технологий доступа к данным».

Вопросы производительности

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

данных. Для обеспечения максимальной пропускной способности при настройке системы

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

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

 Используйте пул подключений и оптимизируйте производительность, исходя из

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

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

Для приложения с высокими требованиями по пропускной способности

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

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

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

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

случая.

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

серверу базы данных.

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

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

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

 В случае применения DataReader используйте последовательный поиск, это

обеспечит большую производительность.

Вопросы безопасности

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

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

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

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

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

 При работе с SQL Server используйте аутентификацию Windows с реализацией

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

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

развертывание».

 Шифруйте строки подключения в конфигурационных файлах, вместо того чтобы

использовать системные или пользовательские DSN.

 Для хранения паролей применяйте не шифрованную версию пароля, а хеш с

шумом.

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

доступа к данным для аудита.

 Используйте параметризованные SQL-запросы и типизированные параметры, чтобы

снизить риски безопасности и сократить шансы на успех атак с внедрением SQL-

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

на базе вводимых пользователем данных

Вопросы развертывания

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

производительность и вопросы безопасности среды производственной эксплуатации. При

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

 Если это не противоречит требованиям масштабирования и безопасности,

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

лучшую производительность приложения.

 Если требуется поддерживать удаленный уровень доступа к данным, улучшить

производительность позволит применение протокола TCP.

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

отличном от сервера базы данных. Физические характеристики сервера базы

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

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

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

снижению производительности приложения.

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

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

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

развертывания приложения. В этом разделе кратко представлен эффективный подход к

проектированию слоя доступа к данным. Рассмотрим основные этапы проектирования слоя

доступа к данным:

1. Создайте общий дизайн слоя доступа к данным. Выберите, с какой средой будете

работать, greenfield или brownfield, и, исходя из этого, определите ограничения

источника данных и соответствующие ограничения слоя данных. Кроме того, в

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

сосуществовать с источником данных в его текущем состоянии.

◦ В сценарии с использованием среды greenfield вы имеете полный контроль

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

обуславливаются самим источником данных.

◦ В сценарии с использованием среды brownfield вы не обладаете контролем

над схемами источника данных, и в его качестве может выступать все, что

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

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

структуру и ограничения существующего бизнеса. Например, выясните,

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

ограничения, которые помешают изменить существующую схему. Но, как

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

существующую схему. Также определитесь, как будет осуществляться

взаимодействие со слоем данных: через Веб-сервисы или с помощью

устаревшего приложения, использующего компоненты шлюза. В любом

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

контракте Веб-сервиса или в интерфейсе, предоставляемом компонентами

шлюза.

2. Выберите необходимые типы сущностей. Компоненты доступа к данным работают

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

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

код валидации. Также важно правильно выбрать тип и формат данных бизнес-

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

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

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

данных, можно найти в главе 13, «Проектирование бизнес-сущностей». При выборе

формата данных обратите внимание на следующие аспекты:

◦ Если требуется поддерживать сценарии без постоянного подключения в

простых приложениях, выполняющих CRUD-операции, используйте объекты

DataSet или отдельные DataTable. Самым распространенным подходом

является применение ADO.NET. Это идеальный вариант при работе с

существующим приложением, в котором уже используются ADO.NET. При

проектировании нового приложения можно применять LINQ to Datasets для

заполнения DataSet с помощью запросов LINQ.

◦ Если к слою доступа к данным будут обращаться другие приложения или

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

или платформами, используйте формат XML.

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

приложения, применяйте специальные бизнес-сущности. Для этого

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

операциями базы данных, но решения O/RM могут облегчить задачу

разработчика. Для обеспечения большей гибкости используйте ADO.NET

Entity Framework или другие O/RM-средства, такие как инструментарий с

открытым исходным кодом NHibernate.

◦ Реализуйте сущности, наследуя их от базового класса, который

обеспечивает основную функциональность и инкапсулирует выполнение

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

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

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

производительности.

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

полагаясь на компоненты логики доступа к данным. Обеспечьте

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

соответствующей бизнес-логики. Например, если бизнес-сущности

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

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

разрешение на подключение к 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/en-

us/library/ms978510.aspx#daag_handlingblobs.

 «Using stored procedures instead of SQL statements» (Использование хранимых

процедур вместо SQL-выражений) по адресу http://msdn.microsoft.com/en-

us/library/ms978510.aspx.

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

Рекомендации по

проектированию слоя

сервисов

Обзор

При предоставлении доступа к функциональности приложения через сервисы функции

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

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

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

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

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

В слое сервисов определяется и реализуется интерфейс сервиса и контракты данных (или типы

сообщений). Одним из самых важных моментов, о котором нельзя забывать, является то, что

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

используемых в приложении. В частности, необходимо гарантировать, что сущности бизнес-

слоя не будут оказывать большого влияния на контракты данных. Слой сервисов должен

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

форматов данных между сущностями бизнес-слоя и контрактами данных.

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

Рис. 10

Типовое приложение со слоем сервисов

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

 Интерфейсы сервисов. Сервисы предоставляют интерфейсы, в которые передаются

все входящие сообщения. Интерфейс сервиса можно рассматривать как фасад,

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

реализованной в приложении (как правило, логику бизнес-слоя).

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

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

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

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

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

главе 10, «Рекомендации по проектированию компонентов». О проектировании интерфейсов

сервисов рассказывает глава 18, «Взаимодействие и обмен сообщениями».

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

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

аспектов проектирования касаются проверенных практик, имеющих отношение к созданию

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