В чем разница между «уровнем обслуживания данных» и «уровнем доступа к данным»?

Question

Я помню, что читал, что один абстрагирует низкоуровневые вызовы в независимую от данных среду (например, методы ExecuteCommand и т. Д.), А другой обычно содержит специфичные для бизнеса методы (например, UpdateCustomer).

Это правильно? Что есть что?

Answer 1

Для меня это личное дизайнерское решение о том, как вы хотите обработать свой проект. Время от времени доступ к данным и обслуживание данных - это одно и то же. Для .NET и LINQ это так.

Для меня уровень обслуживания данных - это то, что фактически выполняет вызов к базе данных. Уровень доступа к данным получает объекты и создает их или изменяет их для уровня обслуживания данных, чтобы выполнить вызов к базе данных.

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

Answer 2

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

Уровень доступа к данным находится на границе между данными и приложением. «Данные» - это просто разнообразный набор источников данных, используемых приложением. Это может означать, что в каждом приложении необходимо выполнить существенное кодирование, чтобы собрать данные из нескольких источников. Код, который создает требуемые представления данных, будет избыточным в некоторых приложениях.

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

Возможно разделение уровня сервисов данных на его составные части (то есть доступ к данным, преобразование и интеграция). В таком случае у вас может быть «Уровень доступа к данным», который занимается только извлечением данных, и «Уровень обслуживания данных», который извлекает свои данные через уровень доступа к данным и объединяет и преобразует извлеченные данные в различные объекты, необходимые для уровень бизнес-услуг.

Answer 3

Вот еще одна перспектива глубоко из окопов! Уровень доступа к данным - это уровень программной абстракции, который скрывает сложность / реализацию фактического получения данных. Приложения запрашивают уровень доступа к данным (см. Шаблон проектирования DAO), чтобы «получить мне это» или «обновить это» и т. Д. (Косвенное обращение). Уровень доступа к данным отвечает за выполнение специфических для реализации операций, таких как чтение / обновление различных источников данных, таких как Oracle, MySQL, Cassandra, RabbitMQ, Redis, простая файловая система, кэш или даже делегирование другому уровню обслуживания данных. ,

Если вся эта работа происходит внутри одного компьютера и в одном и том же приложении, термин Уровень обслуживания данных эквивалентен Фасаду обслуживания (косвенное указание). Он отвечает за обслуживание и делегирование вызовов приложений нужному уровню доступа к данным.

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

Так что, для ясности, приложение использует DSL и DAL. DSL в приложении должен общаться с DAL в том же приложении. У DAL есть выбор использования одного источника данных или делегирование другому веб-сервису. Веб-служба DSL может делегировать работу DAL для этого запроса. Действительно, для одного запроса веб-службы можно использовать несколько источников данных для ответа на данные.

Учитывая все сказанное с прагматической точки зрения, только когда системы становятся все более сложными, следует уделять больше внимания архитектурным образцам. Хорошая практика - делать все правильно, но нет смысла излишне покрывать золотом свою работу. Помните ЯГНИ? Ну, это не резонирует, придет время, когда это необходимо!

В заключение: знаменитый афоризм Дэвида Уилера гласит: «Все проблемы в области компьютерных наук могут быть решены с помощью другого уровня косвенности»; [1] это часто намеренно неправильно цитируют, используя «уровень абстракции», заменяемый уровнем окольные». Следствие Кевлина Хенни к этому таково: «… за исключением проблемы слишком большого числа уровней косвенности».

Answer 4

Концепция уровня обслуживания данных , реализованная в документации WebSphere Commerce , проста:

Уровень обслуживания данных (DSL) обеспечивает уровень абстракции для доступа к данным, который не зависит от физической схемы. Цель уровня обслуживания данных состоит в том, чтобы предоставить согласованный интерфейс (называемый фасадом службы данных) для доступа к данным, независимый от инфраструктуры объектно-реляционного отображения

В настоящее время в Интернете концепция DSL в основном связана с SOA (Сервис-ориентированные архитектуры), но не только. Здесь упоминается в примере приложений N-уровня.