В чем разница между уровнем абстракции базы данных и уровнем доступа к данным?
Я на самом деле застрял в 3-х уровневой структуре. Я просмотрел Интернет и нашел две терминологии "Уровень абстракции базы данных" и "Уровень доступа к данным".
Каковы различия между этими двумя?
3 ответа
Насколько я понимаю, уровень доступа к данным на самом деле не абстрагирует базу данных, а облегчает операции с базами данных и построение запросов.
Например, слои доступа к данным обычно имеют API, очень похожие на синтаксис SQL, которые все еще требуют знания структуры базы данных для записи:
$Users->select('name,email,datejoined')->where('rank > 0')->limit(10);
Слои абстракции данных обычно представляют собой полнофункциональные ORM (объектно-реляционные сопоставители), которые теоретически исключают необходимость понимания какой-либо базовой структуры базы данных или какого-либо знания SQL. Синтаксис может быть что-то вроде этого:
Factory::find('Users', 10)->filter('rank > 0');
И все объекты могут быть полностью заполнены всеми полями, возможно, соединены с любыми родительскими или дочерними объектами, если вы установите его таким образом.
Однако эта абстракция имеет свою цену. Лично я нахожу, что доктрина ORM или доктрина не нужны и неэффективны. В большинстве случаев достаточно простого слоя доступа к данным, с ручным SQL для всего, что требует особого внимания, вместо того, чтобы разрушать производительность вашего приложения из-за некоторого синтаксического сахара. Эта область - довольно жаркие дебаты, поэтому я не буду вдаваться в подробности.
Если вы имеете в виду уровень абстракциибазы данных, то это будет нечто вроде PDO, так что ваш код можно будет использовать для большего числа поставщиков баз данных. Я полагаю, что PDO работает с MySQL, PostgreSQL и mysqli.
Уровень доступа к данным = операции создания, чтения, обновления, удаления (CRUD), характерные для вашего домена приложения
Уровень абстракции данных = выполняет общие операции с базой данных, такие как соединения, команды, параметры, изолирующие вас от специфических библиотек данных поставщика и обеспечивающие один API высокого уровня для доступа к данным, независимо от того, используете ли вы MySQL, Microsoft SQL Server, Oracle, DB2 и т. Д....
Из вики:
Уровень доступа к данным (DAL) в компьютерном программном обеспечении - это уровень компьютерной программы, который обеспечивает упрощенный доступ к данным, хранящимся в каком-либо постоянном хранилище, таком как объектно-реляционная база данных.
Например, DAL может возвращать ссылку на объект (в терминах объектно-ориентированного программирования) вместе с его атрибутами вместо строки полей из таблицы базы данных. Это позволяет создавать клиентские (или пользовательские) модули с более высоким уровнем абстракции. Модель такого типа может быть реализована путем создания класса методов доступа к данным, которые напрямую ссылаются на соответствующий набор хранимых процедур базы данных. Другая реализация может потенциально извлекать или записывать записи в или из файловой системы. DAL скрывает эту сложность основного хранилища данных от внешнего мира.
Например, вместо использования таких команд, как вставка, удаление и обновление, для доступа к конкретной таблице в базе данных, в базе данных может быть создан класс и несколько хранимых процедур. Процедуры будут вызываться из метода внутри класса, который будет возвращать объект, содержащий запрошенные значения. Или команды вставки, удаления и обновления могут быть выполнены в простых функциях, таких как registeruser или loginuser, хранящихся на уровне доступа к данным.
Короче говоря, основные функциональные возможности / логика CRUD для бизнес-объектов, которые нужно перенести на уровень персистентности / хранилища и получить из него, находятся здесь. В большинстве случаев вам может понадобиться именно это. ORM mapping, интерфейсы бизнес-объектов Model и т. Д. Попадают сюда.
Уровень абстракции базы данных
Уровень абстракции базы данных - это интерфейс прикладного программирования, который объединяет связь между компьютерным приложением и базами данных, такими как SQL Server, DB2, MySQL, PostgreSQL, Oracle или SQLite. Традиционно все поставщики баз данных предоставляют свои собственные интерфейсы, адаптированные к их продуктам, что позволяет программисту приложений реализовывать код для всех интерфейсов баз данных, которые он или она хотели бы поддерживать. Слои абстракции базы данных сокращают объем работы, предоставляя разработчикам согласованный API и максимально скрывая специфику базы данных за этим интерфейсом. Существует множество уровней абстракции с различными интерфейсами на многочисленных языках программирования.
По сути, это дополнительный уровень абстракции, так что вы CRUD против независимых интерфейсов поставщиков и меньше беспокоиться о деталях реализации различных поставщиков баз данных. Это понадобится вам только в том случае, если вы хотите поддерживать более одной базы данных. ORM, Micro ORM, обертки, универсальные классы драйверов, независимо от имени, и т.д., которые имеют отношение к установлению соединения, обработке параметров, выполнению и т. Д., Находятся здесь. Это просто дополнительный слой перед слоем Persistance/Storage. В трехуровневой терминологии оба эти слоя подпадают под один, поскольку они не являются логически разделенными.
Подводя итог, DAL о данных, DbAL о базе данных. DAL определяет операции, DbAL работает. DAL стоит за DbAL, который стоит за фактическим Db. DAL вызывает DbAL. DAL - это хорошая вещь, чтобы отделить бизнес-логику (в модели) от логики CRUD, в то время как DbAL редко требуется (но мне это нравится). DAL - это более высокоуровневое проектирование, DbAL - более низкоуровневая архитектура и реализация. Оба разделяют обязанности. ORM - это огромные структуры, которые делают и то, и другое для вас. Я не уверен, как вы разделяете их при использовании ORM. Вам не нужно, так как ORM все это для вас обрабатывает. В идеале, я бы в любом случае имел DAL в одном проекте и DbAL в другом, который я бы просто назвал слоем постоянства, поскольку нет смысла разделять Db и операции над ним.