Data Mapper - более современная тенденция, чем Active Record

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

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


mysql database design-patterns orm datamapper
person jblue    schedule 30.09.2010    source источник

Ответы (2)


arrow_upward
51
arrow_downward

DataMapper не новее и не новее, а просто больше подходит для ORM.

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

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

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

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

person Gordon    schedule 30.09.2010

arrow_upward
16
arrow_downward

Несмотря на то, что посту 8 лет, вопрос все еще актуален в 2018 году.

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

Хороший дизайн ООП выполняется слоями. Уровень ввода, уровень сервиса, уровень репозитория, преобразователь данных и БД - всего лишь простой пример. Не следует смешивать входной слой с БД. Как это можно сделать? Например, в Laravel вы можете использовать такое правило валидатора:

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

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

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

person Peter Matisko    schedule 12.05.2018