Является ли Data Mapper более современным трендом, чем Active Record

я наткнулся на пару ORMs, которые недавно объявили, что они планируют переместить свою реализацию из Active Record в Data Mapper. Мои знания в этой области весьма ограничены. Итак, вопрос для тех, кто знает лучше, является ли Data Mapper новее, чем Active Record? Было ли это вокруг, когда началось активное движение записи? Как они связаны друг с другом?

наконец, поскольку я не человек базы данных и мало знаю об этом предмете, должен ли я следовать ORM, который движется к реализация Data Mapper, как в том, что в нем для меня, как кто-то пишет программное обеспечение (не человек данных)?

11
database datamapper design-patterns mysql orm

3 ответов

DataMapper не более современный или более новый, но просто более подходит для ORM.

основная причина, по которой люди меняются, потому что ActiveRecord не делает для хорошего ORM. АР обертывает строку в таблице или представлении базы данных, инкапсулирует доступ к базе данных и добавляет логику домена на эти данные. Таким образом, по определению, AR представляет собой 1:1 представление записи базы данных, что делает его особенно подходящим для простого CRUD.

некоторые люди добавили выборку связанных данных в свой AR, что заставило людей поверить, что AR является ORM. Это не. Точки ОРМ является решение объектно-реляционного несоответствия импеданса между структурой базы данных и объектов предметной области. При использовании AR у вас нет этого несоответствия импеданса, потому что ваш AR представляет строку базы данных, а не правильный дизайн OO. Вы привязываете макет БД к своим объектам. Некоторые из объектно-реляционных поведенческих моделей все еще могут быть применены, хотя (например, ленивая загрузка).

еще одна причина, по которой AR часто критикуют, заключается в том, что он смешивает две проблемы: бизнес-логику и логику доступа к БД. Это водит к излишнему соединению и может привести в меньше ремонтопригодности и гибкости в более больших применениях. Между этими двумя слоями нет изоляции. Соединение всегда приводит к меньшей гибкости.

A DataMapper С другой стороны перенос данных между объектами и базой данных, сохраняя их независимо друг от друга и от самого картографа. пока более трудный для того чтобы снабдить, оно учитывает очень более гибкий дизайн в вашем применении. Объекты домена больше не должны соответствовать структуре БД. DAL и доменный слой разделены.

21

мои 2 цента:

DataMapper новее, чем ActiveRecord. Мне больше нравится синтаксис DataMapper; он более явный и менее "волшебный". Я мог бы рассмотреть больше причин, но они перечислены здесь:http://datamapper.org/why

ActiveRecord имеет гораздо больше документации.

0

хотя после 8 лет, вопрос остается в силе в 2018 году.

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

хороший дизайн ООП сделан в слоях. Входной слой, сервисный слой, слой репозитория, Data mapper и DB - простой пример. Вы не следует смешивать входной слой с БД. Как это можно сделать? Например, в Laravel можно использовать следующее правило валидатора:

'email' => 'exists:staff,email'

он проверяет, существует ли электронная почта в персонале таблицы. Это полное отсутствие смысла. Это колготки вашего верхнего слоя с именем столбца DB. Я не могу представить лучшего примера плохого дизайна ООП.

нижняя строка-если вы создаете простой сайт с 2-3 таблицами, например блог, активная запись не может быть проблемой. Для что-нибудь большее, перейдите к Data Mapper и будьте осторожны с принципами ООП, такими как IoC, SoC и т. д.

0