Какова цель уровня доступа к данным?

В двух словах: Слабая связь

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

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

Существует две основные цели уровня доступа к данным.

1. Абстрагируйте фактический механизм базы данных или другое хранилище данных, чтобы ваши приложения могли переключаться с использования, скажем, Oracle на использование сервера MS SQL.

2. Абстрагируйте логическую модель данных таким образом, чтобы ваш бизнес-уровень был отделен от этих знаний и не зависел от них. Предоставление вам возможности изменять логическую модель данных, не влияя на бизнес-уровень.

Большинство ответов здесь указали первую причину. На мой взгляд, гораздо важнее второе. По сути, ваш бизнес-уровень не должен знать об используемой логической модели данных. Сегодня с ORM и Linq № 2, кажется, уходит в окно, и люди склонны забывать (или не в состоянии увидеть тонкие грани, которые существуют и должны существовать) о № 2.

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

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

GetOrdersForCustomer(42)

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

Я написал статью в своем блоге, в которой более подробно.

Назначение и функции уровня доступа к данным< /а>

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

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

Имейте в виду, что DAL также может быть очень контрпродуктивным. Если вы строите систему, в которой скорость доступа к данным имеет решающее значение, отделение ее от бизнес-логики может сделать невозможными некоторые жизненно важные оптимизации.

Уровень доступа к данным следует идее «разделения задач», согласно которой вся логика, необходимая для вашей бизнес-логики для взаимодействия с вашим уровнем данных (базой данных), изолирована в одном наборе классов (слое). Это позволяет вам более легко изменить внутреннюю технологию физического хранения данных (например, перейти от XML-файлов к базе данных или от SQL Server к Oracle или MySQL), не оказывая большого влияния (и, если все сделано правильно, с нулевым влиянием) на ваши бизнес-логика.

Существует множество инструментов, которые помогут вам создать свой слой данных. Если вы ищете фразу "объектно-реляционный преобразователь" или "ORM", вы должны найти более подробную информацию.

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

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

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

Уровень доступа к данным используется для абстрагирования хранения и извлечения данных от их представления. Вы можете больше узнать об этом виде абстракции в 1994 году в Шаблоны проектирования< /а>

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

Преимущества:

• Базовое хранилище может измениться (например, перейти с Oracle на MSSQL), и вам нужен способ локализовать эти изменения.
• Изменения схемы - см. выше
• Вам нужен способ запуска без подключения к базе данных (демонстрационный режим): добавьте сериализацию/десериализацию файлов в DAL.

Я рекомендую вам прочитать здесь: http://msdn.microsoft.com/en-us/practices/default.aspx Использование DAL поможет вам изолировать доступ к данным от вашей презентации и бизнес-логики. Я часто использую его, чтобы легко менять (путем отражения и динамической загрузки сборок) поставщиков данных.

Почитайте, там много полезной информации.

Кроме того, загляните в блок доступа к данным, если вы планируете использовать .СЕТЬ. Это может быть большой помощью.

Кое-что, что не было поднято, но я подумал, что я хотел бы добавить, что наличие DAL позволяет вам улучшить безопасность вашей системы. Например, БД и DAL могут работать на серверах, недоступных для общественности, в то время как бизнес-логика может работать на общедоступном сервере, так что общедоступный сервер не может запускать необработанный SQL в БД. Это может помочь смягчить значительный ущерб, если общедоступный сервер будет скомпрометирован.