Почему мне не нужен ORM на таком функциональном языке, как Scala?

Мне интересно, могу ли я переключиться с Java на Scala в проекте Spring + Hibernate, чтобы воспользоваться некоторыми функциями Scala, такими как сопоставление с образцом, Option и, как мне кажется, более чистый синтаксис в целом. Я искал ORM по умолчанию в экосистеме Scala и обнаружил, что он похож на Activate (но в основном я пытаюсь выяснить, можно ли использовать Hibernate с Scala). В поисках этого я читал это в документации Play о JPA + Scala.

Но самый важный момент: действительно ли вам нужен картограф Relationnal to Objects, когда вы обладаете мощью функционального языка? Возможно нет. JPA - это удобный способ абстрагировать недостаток Java в преобразовании данных, но он действительно кажется неправильным, когда вы начинаете использовать его из Scala.

У меня нет глубокого понимания того, как использовать функциональное программирование для создания законченного приложения (вот почему я намереваюсь использовать Scala, чтобы я мог понять это постепенно, так как он объединяет OO + Functional), поэтому я не могу понять, почему мне не нужен ORM с функциональным языком и каков функциональный подход к решению проблемы устойчивости модели предметной области.

Подход DDD для бизнес-логики все еще имеет смысл в Scala, не так ли?

Ну, одна вещь, которую важно делать, когда мы обсуждаем подобное, - это четко различать реляционные объекты (ORM) и уровни абстракции базы данных . ORM является своего рода уровнем абстракции базы данных, но не все уровни абстракции базы данных являются ORM. Одним из хороших инструментов для изучения этого является популярная библиотека Python SQLAlchemy , которая позиционирует себя как «инструментарий SQL и Object Relational Mapper» (мой жирный шрифт) с идеей, что это разные вещи. Как они написали на своей странице основных функций :

ORM не требуется

SQLAlchemy состоит из двух отдельных компонентов, известных как ядро и ORM . Ядро само по себе является полнофункциональным инструментарием абстракции SQL, обеспечивающим плавный уровень абстракции в широком спектре реализаций и поведений DBAPI, а также язык выражений SQL, который позволяет выражать язык SQL через генеративные выражения Python. Система представления схемы, которая может генерировать операторы DDL, а также анализировать существующие схемы, и система типов, которая позволяет любое отображение типов Python на типы базы данных, завершают систему. Object Relational Mapper тогда является необязательным пакетом, который основывается на Ядре.

Главная страница описывает ORM следующим образом:

SQLAlchemy наиболее известен своим объектно-реляционным сопоставителем (ORM), необязательным компонентом, который предоставляет шаблон сопоставления данных, где классы могут быть сопоставлены с базой данных открытым способом, несколькими способами - позволяя объектной модели и схеме базы данных развиваться в Чисто развязанный путь с самого начала.

Ключевой идеей ORM является попытка преодоления известного несоответствия объектно-реляционного импеданса . Это означает определение взаимосвязей между пользовательскими классами с таблицами в схеме базы данных и автоматические операции «сохранения» и «загрузки» для классов вашего приложения.

Напротив, уровни абстракции базы данных, отличные от ORM, как правило, более привязаны к реляционной модели данных и к SQL, а не к объектно-ориентированной. Поэтому вместо того, чтобы показывать «отображения» между таблицами и классами и скрывать схему базы данных от программиста, они стремятся предоставить базу данных программисту, но с лучшими API и абстракциями. Например, построители SQL-запросов позволяют вам генерировать сложные SQL-запросы программно, без манипуляций со строками, например так ( пример из библиотеки jOOQ для Java ):

// Typesafely execute the SQL statement directly with jOOQ
Result<Record3<String, String, String>> result =
    create.select(BOOK.TITLE, AUTHOR.FIRST_NAME, AUTHOR.LAST_NAME)
          .from(BOOK)
          .join(AUTHOR)
          .on(BOOK.AUTHOR_ID.equal(AUTHOR.ID))
          .where(BOOK.PUBLISHED_IN.equal(1948))
          .fetch();

Теперь платформа Play, похоже, не на 100% совпадает с тем, что я только что описал , но их аргумент, похоже, заключается в этом общем пространстве: работать с реляционной моделью напрямую, а не переводить ее в классы и обратно от них.

Библиотека jOOQ заслуживает изучения в качестве контрапункта для ORM. У них также есть некоторые соответствующие записи в блоге, которые стоит прочитать:

• http://blog.jooq.org/2015/03/24/jooq-vs-hibernate-when-to-choose-which/
• http://blog.jooq.org/2014/04/11/java-8-friday-no-more-need-for-orms/

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

ОРМ обычно разрабатываются вокруг этой парадигмы. Вы извлекаете некоторые данные из базы данных, превращаете их в объект, потенциально модифицируете их, и когда вы закончите, у вас все еще будет тот же объект, который вы сможете записать обратно в базу данных.

Функциональное программирование работает по-другому. Ваши данные не сохраняют ни одной идентификационной информации в течение всей жизни. Это разделено, скопировано, разделено, и преобразовано. Он проходит через множество функций, а затем в конечном итоге возвращается в нужную вам форму вывода. Чтобы любой API базы данных казался естественным на функциональном языке, он должен это учитывать, а JPA - нет.

В Scala все еще полезно отображать таблицы базы данных на объекты, и есть несколько способов сделать это.

Один из популярных фреймворков в мире Scala - гладкий . Это не ORM, потому что он делает меньше (а именно, он не извлекает отношения без явного указания делать соединения).

Таким образом, вы по-прежнему сопоставляете объекты со строками базы данных, но ваши объекты являются неизменяемыми (следовательно, не очищаются от состояния), и вы явно выполняете запросы с использованием монадической DSL. В результате вы получаете много «хороших» частей ORM без проблем, связанных с изменчивостью, и непредсказуемых проблем N + 1.

Следует отметить, что люди добились большого успеха, используя гораздо более тонкие библиотеки, такие как anorm или JDBC, используя функциональные методы для поддержания красивого кода.

Одна из фантастических библиотек, которая применяет функциональные методы поверх JDBC, тоже doobie .

Таким образом, у вас есть много вариантов доступа к базе данных, но Hibernate (который, по-видимому, является де-факто ORM) не является одним из лучших из-за склонности к изменчивости.

Вам не нужен ORM даже в объектно-ориентированных языках.

Во-первых, кто сказал, что ваши данные должны быть физически скопированы из вашего постоянного хранилища на ваш объект? Алан Кей , человек из Smalltalk, хотел, чтобы объекты избавлялись от данных . Он предположил, что объект может иметь только ссылку на некоторую область, где хранятся его данные.

Второе - как лучше всего этого достичь? Я рекомендую идентифицировать ваши объекты по их обязанностям , а не думать о данных, которыми они обладают. Если вы слышали о подходе CRC-карт, он используется именно для этого.

И, наконец, на тот случай, если вы когда-нибудь вернетесь в ОО-поле, вот способ реализовать это .