Какую Java ORM вы предпочитаете и почему? [закрыто]

Это довольно открытый вопрос. Я начну новый проект и рассмотрю различные ORM для интеграции с доступом к базе данных.

У тебя есть любимые? Есть ли что-нибудь, что вы бы посоветовали держаться подальше?

Я перестал использовать ORM.

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

Так что подумайте только об использовании пакета JDBC.

Нет, потому что наличие ORM отнимает слишком много контроля с небольшими преимуществами. Полученная экономия времени легко сходит на нет, если вам необходимо отладить отклонения, возникающие в результате использования ORM. Кроме того, ORM не позволяют разработчикам изучать SQL и принципы работы реляционных баз данных и использовать их в своих интересах.

Многие ORM великолепны, вам нужно знать, почему вы хотите добавить абстракцию поверх JDBC. Я могу порекомендовать вам http://www.jooq.org (отказ от ответственности: я создатель jOOQ, поэтому этот ответ предвзят). JOOQ охватывает следующую парадигму:

• SQL это хорошая вещь. Многие вещи могут быть выражены довольно хорошо в SQL. Нет необходимости в полной абстракции SQL.
• Модель реляционных данных - это хорошо. Он доказал лучшую модель данных за последние 40 лет. Нет необходимости в базах данных XML или действительно объектно-ориентированных моделях данных. Вместо этого ваша компания использует несколько экземпляров Oracle, MySQL, MSSQL, DB2 или любой другой СУБД.
• SQL имеет структуру и синтаксис. Это не должно быть выражено с использованием «низкоуровневой» конкатенации строк в JDBC - или «высокоуровневой» конкатенации строк в HQL - обе из них подвержены синтаксическим ошибкам.
• Привязка к переменной имеет тенденцию быть очень сложной при работе с основными запросами. Это то, что должно быть абстрагировано.
• POJO отлично подходят для написания кода Java, манипулирующего данными базы данных.
• POJO - это боль писать и поддерживать вручную. Генерация кода это путь. Вы будете иметь безопасные для компиляции запросы, включая безопасность типов данных.
• База данных на первом месте. Хотя приложение поверх вашей базы данных может со временем меняться, сама база данных, вероятно, будет работать дольше.
• Да, у вас есть хранимые процедуры и пользовательские типы (UDT) в вашей устаревшей базе данных. Ваша база данных должна поддерживать это.

Есть много других хороших ORM. Особенно Hibernate или iBATIS имеют отличное сообщество. Но если вы ищете интуитивный, простой, я скажу попробовать JOOQ. Тебе это понравится! :-)

Проверьте этот пример SQL:

  // Select authors with books that are sold out
  SELECT * 
    FROM T_AUTHOR a
   WHERE EXISTS (SELECT 1
                   FROM T_BOOK
                  WHERE T_BOOK.STATUS = 'SOLD OUT'
                    AND T_BOOK.AUTHOR_ID = a.ID);

И как это можно выразить в jOOQ:

  // Alias the author table
  TAuthor a = T_AUTHOR.as("a");

  // Use the aliased table in the select statement
  create.selectFrom(a)
        .whereExists(create.selectOne()
                           .from(T_BOOK)
                           .where(T_BOOK.STATUS.equal(TBookStatus.SOLD_OUT)
                           .and(T_BOOK.AUTHOR_ID.equal(a.ID))))));

Hibernate, потому что это в основном стандарт де-факто в Java и был одной из движущих сил в создании JPA. Он получил отличную поддержку в Spring, и почти каждая инфраструктура Java поддерживает его. Наконец, GORM - это действительно классная оболочка, которая делает динамические поиски и так далее, используя Groovy.

Он даже был портирован на .NET (NHibernate), так что вы также можете использовать его там.

Спящий, потому что это:

• Стабильно - находясь рядом столько лет, ему не хватает серьезных проблем.
• диктует стандарты в области ORM
• реализует стандарт (JPA), в дополнение к его диктовке.
• имеет тонны информации об этом в Интернете. Есть много учебных пособий, общих решений проблем и т. Д.
• является мощным - вы можете перевести очень сложную объектную модель в реляционную модель.
• он поддерживает любые основные и средние СУБД
• с ним легко работать, если вы хорошо его освоите

Несколько моментов о том, почему (и когда) использовать ORM:

• вы работаете с объектами в вашей системе (если ваша система была разработана хорошо). Даже если вы используете JDBC, вы в конечном итоге создадите слой перевода, чтобы перенести свои данные в ваши объекты. Но я уверен, что hibernate лучше при переводе, чем любое другое решение.
• это не лишает вас контроля. Вы можете управлять вещами очень мелкими деталями, и, если у API нет какой-либо удаленной функции, выполните собственный запрос, и он у вас есть.
• любая система среднего или большего размера не может позволить себе иметь одну тонну запросов (будь то в одном месте или разбросанных по всему), если она стремится обслуживаться
• если производительность не критична. Hibernate добавляет снижение производительности, которое в некоторых случаях нельзя игнорировать.

Я бы порекомендовал использовать MyBatis . Это тонкий слой поверх JDBC, очень легко отображать объекты в таблицы и при этом использовать простой SQL, все находится под вашим контролем.

У меня был действительно хороший опыт работы с Avaje Ebean когда я писал приложение JavaSE среднего размера.

Он использует стандартные аннотации JPA для определения сущностей, но предоставляет гораздо более простой API (без EntityManager или какой-либо другой хрени с присоединенными / отсоединенными сущностями). Это также позволяет вам легко использовать SQL-запросы или простые JDBC-вызовы при необходимости.

Он также имеет очень приятный и безопасный API для запросов. Вы можете написать такие вещи, как:

List<Person> boys = Ebean.find(Person.class)
                                  .where()
                                       .eq("gender", "M")
                                       .le("age", 18)
                                  .orderBy("firstName")
                                  .findList();

SimpleORM , потому что это просто и без магии. Он определяет все структуры метаданных в коде Java и является очень гибким.

SimpleORM предоставляет функциональность, аналогичную Hibernate, путем сопоставления данных в реляционной базе данных с объектами Java в памяти. Запросы могут быть заданы в терминах объектов Java, идентичность объекта совпадает с ключами базы данных, отношения между объектами поддерживаются, а измененные объекты автоматически сбрасываются в базу данных с оптимистическими блокировками.

Но, в отличие от Hibernate, SimpleORM использует очень простую объектную структуру и архитектуру, которая позволяет избежать необходимости сложного анализа, обработки байтового кода и т. Д. SimpleORM является небольшим и прозрачным, упакован в две банки размером всего 79 КБ и 52 КБ, с одной маленькой и опциональной зависимость (Slf4j). (Hibernate более 2400K плюс около 2000K зависимых JAR-файлов.) Это упрощает понимание SimpleORM и значительно снижает технический риск.

Eclipse Link , по многим причинам, но особенно я чувствую, что у него меньше вздутия, чем у других решений основного потока (по крайней мере, меньше вздутие живота)

Ох, и Eclipse Link была выбрана в качестве эталонной реализации для JPA 2.0

Хотя я разделяю озабоченность по поводу замены Java для запросов SQL в свободной форме, я действительно думаю, что люди, критикующие ORM, делают это из-за в целом плохого дизайна приложений.

Истинный OOD определяется классами и отношениями, а ORM обеспечивает согласованное отображение различных типов отношений и объектов. Если вы используете инструмент ORM и в конечном итоге кодируете выражения запросов на любом языке запросов, поддерживаемом платформой ORM (включая, помимо прочего, деревья выражений Java, методы запросов, OQL и т. Д.), Вы определенно делаете что-то неправильно, то есть модель вашего класса. скорее всего, не поддерживает ваши требования так, как должно. Чистый дизайн приложения на самом деле не требует запросов на уровне приложения. Я проводил рефакторинг многих проектов, которые люди начинали использовать ORM-фреймворк так же, как они использовались для встраивания строковых констант SQL в их код, и в итоге все были удивлены тем, насколько простым и понятным становится все приложение, когда вы соответствуете до модели вашего класса с моделью использования. Конечно, для таких вещей, как функциональность поиска и т. Д. Вам нужен язык запросов, но даже в этом случае запросы настолько ограничены, что создание даже сложного VIEW и отображение его на постоянный класс, доступный только для чтения, гораздо приятнее поддерживать и смотреть, чем создавать выражения на некотором языке запросов в коде вашего приложения. Подход VIEW также использует возможности базы данных и, благодаря материализации, может быть намного лучше с точки зрения производительности, чем любой рукописный SQL в вашем источнике Java. Таким образом, я не вижу никакой причины для нетривиального приложения НЕ использовать ORM. но даже в этом случае запросы настолько ограничены, что создание даже сложного VIEW и отображение его на постоянный класс, доступный только для чтения, гораздо приятнее в обслуживании и взгляде, чем построение выражений на каком-либо языке запросов в коде вашего приложения. Подход VIEW также использует возможности базы данных и, благодаря материализации, может быть намного лучше с точки зрения производительности, чем любой рукописный SQL в вашем источнике Java. Таким образом, я не вижу никакой причины для нетривиального приложения НЕ использовать ORM. но даже в этом случае запросы настолько ограничены, что создание даже сложного VIEW и отображение его на постоянный класс, доступный только для чтения, гораздо приятнее в обслуживании и взгляде, чем построение выражений на каком-либо языке запросов в коде вашего приложения. Подход VIEW также использует возможности базы данных и, благодаря материализации, может быть намного лучше с точки зрения производительности, чем любой рукописный SQL в вашем источнике Java. Таким образом, я не вижу никакой причины для нетривиального приложения НЕ использовать ORM.