Более подробно компоненты, обычно используемые в слое доступа к данным, рассматриваются в главе 10, «Рекомендации по проектированию компонентов». Вопросам проектирования компонентов доступа к данным посвящена глава 15, «Проектирование компонентов слоя доступа к данным».

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

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

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

Используйте абстракцию для реализации слабо связанного интерфейса слоя доступа к данным. Этот подход можно реализовать путем определения интерфейсных компонентов, таких как шлюз с общеизвестными входными и выходными параметрами, который преобразует запросы в формат, понятный компонентам слоя. Кроме того, с помощью интерфейсных типов или абстрактных базовых классов можно определить совместно используемую абстракцию, которая должна быть реализована интерфейсными компонентами. Абстракция слоя более подробно рассматривается в главе 5, «Рекомендации по проектированию многослойных приложений».

Инкапсулируйте функциональность доступа к хранилищу данных в слое доступа к данным. Слой доступа к данным должен скрывать детали доступа к источнику данных. Он должен обеспечивать управление подключениями, формирование запросов и сопоставление сущностей приложения со структурами источника данных. Потребители слоя доступа к данным взаимодействуют с ним через абстрактные интерфейсы с использованием сущностей приложения, таких как объекты предметной области, типизированные наборы данных (Typed DataSet) и

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

Примите решение о том, как будет выполняться сопоставление сущностей приложения со структурами источника данных. Тип сущности, используемой в приложении, является основным фактором при принятии решения о методе сопоставления этих сущностей со структурами источника данных. Обычно для этого используются шаблоны Domain Model или Table Module либо механизмы Объектнореляционного сопоставления (Object/Relational Mapping, O/RM), однако, бизнес-

сущности могут быть реализованы с использованием разнообразных подходов22. Необходимо определить стратегию заполнения бизнес-сущностей или структур данных из источника данных и их предоставления для доступа с бизнес-слоя или слоя представления приложения. Шаблоны Domain Model и Table Module более подробно рассматриваются в разделе «Шаблоны проектирования» ближе к окончанию данной главы. Больше сведений о бизнес-сущностях и форматах данных можно найти в главе 13, «Проектирование бизнес-сущностей».

Рассмотрите возможность объединения структур данных. При предоставлении данных через сервисы воспользуйтесь Объектами передачи данных (Data Transfer Objects, DTO), они помогут организовать данные в унифицированные структуры. Кроме того, объекты DTO позволяют реализовать слабо детализированные операции, обеспечивая при этом структуру для перемещения данных через границы. Объекты DTO также могут объединять бизнес-сущности при выполнении агрегированных операций. При использовании шаблона Table Data Gateway или Active Record данные могут быть представлены с помощью класса DataTable (Таблица данных).

Примите решение о том, как будет реализовано управление подключениями.

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

Определите, как будут обрабатываться исключения, возникающие при обработке данных. Слой доступа к данным должен перехватывать и обрабатывать (по крайней мере, обеспечивать начальный этап) все исключения, связанные с источниками данных и операциями CRUD (Create, Read, Update и Delete). Исключения,

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

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

22 В том числе и несовместимых с описанными выше шаблонами сопоставления (прим.

научного редактора).