Я помню, что читал, что один абстрагирует вызовы низкого уровня в агностической структуре данных (например, методы ExecuteCommand и т.д.), а другой обычно содержит специфические для бизнеса методы (например, UpdateCustomer).
Это правильно? Что такое?
Для меня это личное дизайнерское решение о том, как вы хотите справиться с проектом. Иногда доступ к данным и служба данных являются одними и теми же. Для .NET и LINQ это так.
Для меня уровень обслуживания данных - это то, что на самом деле вызывает вызов в базе данных. Уровень доступа к данным принимает объекты и создает их или модифицирует их для уровня службы данных, чтобы сделать вызов в базу данных.
В моих проектах Business Logic Layer манипулирует объектами на основе бизнес-правил, затем передает их на уровень доступа к данным, который отформатирует их для перехода в базу данных или объекты из базы данных, а уровень обслуживания данных обрабатывает фактический вызов базы данных.
Я думаю, что в целом два термина являются взаимозаменяемыми, но могут иметь более конкретные значения в зависимости от контекста вашей среды разработки.
Уровень доступа к данным находится на границе между данными и приложением. "Данные" - это просто разнообразный набор источников данных, используемых приложением. Это может означать, что в каждом приложении должно выполняться существенное кодирование для сбора данных из нескольких источников. Код, который создает требуемые виды данных, будет избыточным в некоторых приложениях.
По мере того, как количество источников данных растет и становится более сложным, возникает необходимость изолировать различные задачи доступа к данным для адресации доступа, преобразования и интеграции данных. Благодаря хорошо продуманным службам данных Business Services смогут взаимодействовать с данными на более высоком уровне абстракции. Логика данных, которая обрабатывает доступ к данным, интеграцию, семантическое разрешение, преобразование и реструктуризацию для удовлетворения представлений и структур данных, необходимых для приложений, наилучшим образом инкапсулируется на уровне данных.
Можно сломать слой служб данных еще дальше в его составные части (т.е. доступ к данным, преобразование и интеграцию). В таком случае у вас может быть "уровень доступа к данным", который касается только получения данных, и "уровня обслуживания данных", который извлекает свои данные через уровень доступа к данным и объединяет и преобразует извлеченные данные в различные объекты, требуемые уровень обслуживания бизнеса.
Здесь еще одна перспектива глубоко из траншей! Уровень доступа к данным - это уровень абстракции программного обеспечения, который скрывает сложность/реализацию фактического получения данных. Приложения запрашивают уровень доступа к данным (см. Шаблон проектирования DAO), чтобы "получить меня это" или "обновить" и т.д. (Косвенность). Уровень доступа к данным отвечает за выполнение конкретных операций, таких как чтение/обновление различных источников данных, таких как Oracle, MySQL, Cassandra, RabbitMQ, Redis, простая файловая система, кеш или даже делегирование на другой уровень обслуживания данных,
Если все это происходит внутри одной машины и в том же приложении, термин "Уровень обслуживания данных" эквивалентен Service Facade (косвенность). Он отвечает за обслуживание и делегирование вызовов приложений на правильный уровень доступа к данным.
Несколько смутно, в распределенном мире вычислений или в сервис-ориентированной архитектуре уровень обслуживания данных фактически может быть веб-сервисом, который действует как автономное приложение. В этом контексте делегаты уровня данных передают полученные запросы данных приложения вверх на правильный уровень доступа к данным. В этом случае веб-сервисы косвенно обеспечивают доступ к данным из приложений - приложение должно знать только, какую услугу вызывать для получения данных, как правило, в распределенных вычислительных средах, этот подход уменьшит сложность приложения (и всегда есть исключительные случаи)
Итак, чтобы быть понятным, приложение использует DSL и DAL. DSL в приложении должен разговаривать с DAL в том же приложении. У DAL есть выбор использования одного источника данных или делегирования другому веб-сервису. Веб-служба DSL может делегировать работу DAL для этого запроса. В самом деле, для одного запроса веб-службы можно использовать несколько источников данных для ответа на данные.
При всем сказанном, с прагматической точки зрения, только когда системы становятся все более сложными, следует уделять больше внимания архитектурным узорам. Это хорошая практика, чтобы делать все правильно, но нет смысла излишне покрывать золотом вашу работу. Помните YAGNI? Ну, что не резонирует, придет время, в которое оно нуждается!
В заключение: известный афоризм Дэвида Уилера гласит: "Все проблемы в информатике могут быть решены другим уровнем косвенности" [1], это часто преднамеренно неверно цитируется с "уровнем абстракции", заменяющим "уровень окольные". Кевлин Хенни, связанный с этим, "... за исключением проблемы слишком большого количества слоев косвенности".
Концепция Уровень обслуживания данных, сделанный в WebSphere Commerce, прост:
Уровень обслуживания данных (DSL) обеспечивает уровень абстракции для доступа к данным, который не зависит от физической схемы. Цель уровня обслуживания данных - обеспечить согласованный интерфейс (называемый фасад службы данных) для доступа к данным, независимо от структуры объектно-реляционного сопоставления
В настоящее время в Интернете концепция DSL в основном связана с SOA (сервис-ориентированные архитектуры), но не только. Здесь упоминается в примере приложений N-уровня.