ActiveRecord против DataMapper
Теперь, в моем втором модуле в Школе программного обеспечения и дизайна Тьюринга, мы много узнали об ORM (объектно-реляционном картографе), известном как ActiveRecord, который многие в сообществе Ruby/Rails часто называют «любимым ORM в Интернете». Вероятно, из-за его интуитивно понятного и удобного характера. Хотя я согласен с тем, что ActiveRecord — отличный инструмент для взаимодействия с базой данных и создания объектов из строк в таблице, и на данном этапе моего обучения разработке программного обеспечения мне больше ничего не нужно, я не мог не задаться вопросом, какие еще типы ORM были там, о которых я еще не слышал, с которыми я мог бы поэкспериментировать в ближайшем будущем. Я решил провести небольшое исследование и наткнулся на шаблон ORM, известный как Data Mapper.
Позвольте мне начать с краткого изложения того, что такое ORM и почему они важны. ORM или Object Relational Mapper/Mapping — это метод программирования, который позволяет нам взаимодействовать между двумя несовместимыми системами типов в объектно-ориентированных языках программирования, таких как Ruby. Это позволяет общаться и взаимодействовать с базой данных из языка программирования, что является эффективной альтернативой использованию чистого SQL. Кроме того, это очень полезно, поскольку позволяет нам, как разработчикам, сосредоточить больше наших когнитивных ресурсов и энергии на логике, а не на длинных SQL-запросах, что приводит к более лаконичному и удобочитаемому коду. Два самых популярных ORM в Rails — как вы уже догадались: ActiveRecord и DataMapper.
Первым и наиболее часто используемым ORM является ActiveRecord. Это ORM Rails по умолчанию. Как упоминалось выше, этот ORM очень популярен среди разработчиков из-за его интуитивности и удобства для пользователя. Это делает его идеальным инструментом для начинающих разработчиков и не только, которые хотят создавать отличные базовые приложения на Rails. ActiveRecord великолепен в том смысле, что он направлен на создание бесшовного моста между приложением и базой данных, создание объектов и довольно простая передача их туда и обратно. Кроме того, данные представлены в виде моделей, что позволяет нам реализовывать ассоциации и отношения между таблицами с использованием этих моделей. Кроме того, из-за тесного соответствия записей в базе данных и объектов в системе очень удобно исследовать схему проекта и иметь хорошее представление о том, что делает проект на высоком уровне. Однако у ActiveRecord также есть некоторые недостатки и законные причины, по которым многие люди ищут альтернативные ORM. Одним из самых больших критических замечаний в отношении ActiveRecord является то, что он нарушает так называемый принцип единой ответственности. По сути, ActiveRecord делает то, что когда объект создается, он представляет только отдельный объект в таблице базы данных, но когда вызывается метод ActiveRecord, он вызывается для всей коллекции объектов. Многие считают, что это слишком большая функциональность, прямо нарушающая SRP (принцип единой ответственности), и ее следует разделить.
Второй ORM, о котором вы, скорее всего, услышите, называется DataMapper. Он создан по образцу шаблона отображения данных для взаимодействия с базами данных. В то время как ActiveRecord создает кажущуюся невидимой связь между базой данных и приложением, DataMapper хочет, чтобы пользователь думал о них более независимо. Это приводит к тому, что DataMapper игнорирует базу данных, если только она не включена в класс в качестве модуля, что делает модель PORO (обычный старый рубиновый объект) с бизнес-логикой. Некоторые явные недостатки DataMapper заключаются в том, что он не очень удобен для пользователя и его будет намного сложнее настроить.
В заключение, оба ORM имеют очевидные варианты использования и преимущества, и любому разработчику было бы очень полезно иметь хотя бы некоторый опыт работы с обоими картографами. Что касается того, когда использовать тот или иной вариант, это полностью зависит от нас, разработчиков, чтобы выбрать тот, который наиболее подходит для конкретного случая использования.
