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