Что бы вы подумали о новом инструменте сохранения Java, который на самом деле не является ORM? [закрыто]

12

Постоянство в Java

За последние годы я накопил опыт в области абстрагирования персистентности в Java, используя такие концепции, как EJB 2.0, Hibernate, JPA и отечественные. Мне показалось, что у них крутая кривая обучения и много сложностей. Кроме того, как большой поклонник SQL, я также подумал, что многие модели абстракции предоставляют слишком много абстракции по сравнению с SQL, создавая такие понятия, как «критерии», «предикаты», «ограничения», которые являются очень хорошими понятиями, но не SQL.

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

jOOQ

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

  • Специфичный для домена язык на основе SQL
  • Генерация исходного кода, отображающая базовую схему базы данных на Java
  • Поддержка многих СУБД

Добавление некоторых функций, которые есть у некоторых современных инструментов персистентности (поправьте меня, если я ошибаюсь):

  • Поддержка сложных SQL - объединений, вложенных выборок, самосоединений, псевдонимов, предложений case, арифметических выражений
  • Поддержка нестандартных SQL - хранимых процедур, UDT, ENUMS, нативных функций, аналитических функций

Пожалуйста, рассмотрите страницу документации для более подробной информации: http://www.jooq.org/learn.php . Вы увидите, что очень похожий подход реализован в Linq для C #, хотя Linq не предназначен исключительно для SQL.

Вопрос

Теперь, сказав, что я большой поклонник SQL, мне интересно, поделятся ли другие разработчики моим энтузиазмом по поводу jOOQ (или Linq). Является ли такой подход к абстракции постоянства жизнеспособным? Какие преимущества / недостатки вы можете увидеть? Как я могу улучшить jOOQ, и чего, по вашему мнению, не хватает? Где я ошибся, концептуально или практически?

Критические, но конструктивные ответы приветствуются

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

Лукас Эдер
источник
Он обрабатывает транзакции?
Арманд
@Alison: нет, это просто SQL. Обработка транзакций - очень сложный бизнес, и я думаю, что многие другие инструменты / фреймворки (включая EJB2 / 3) будут работать лучше, чем jOOQ
Lukas Eder
Я настоятельно рекомендую очень солидный и детальный вариант использования, где вы демонстрируете, что ваш подход отлично подходит для его решения.
Также обратите внимание, что редактирование этого тяжелого варианта сделает ответы более или менее неактуальными и, следовательно, непригодными для будущих читателей. Задайте новый, а лучше вопрос вместо этого.
Привет Торбьерн Вы имеете в виду вариант использования, отличный от тех, которые показаны на странице примеров? Или вы хотели бы видеть некоторые примеры в самом вопросе? Насчет правки: ты в общем прав. В этом случае, однако, я думал, что два ответа, которые я получил до сих пор, были бы несколько одинаковыми ...
Лукас Эдер

Ответы:

5

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

Я тоже искал долго и упорно полнофункциональное решение ORM, который будет соответствовать моим потребностям, но каждое решение, которое я смотрел на подошло короткое. У каждого есть свои плюсы и минусы, но на самом деле никто не сделал все, что я хотел. Я согласен с вашей критикой этих решений, а именно то, что они, как правило, являются сложными и имеют крутой кривой обучения.

Главным претендентом должен был стать де-факто стандарт, Hibernate. Это полнофункциональный, надежный и хорошо проверенный. Я уважаю это и ценю это для того, что это. Теперь, рискуя оскорбить половину сообщества программистов, я также должен сказать, что это раздутый и сложный фрагмент неисполненного кода. Я потратил немало времени, ковыряясь в недрах, пытаясь отладить и понять это, и меня не впечатлило то, что я увидел. Сказав это, я все равно рекомендую его как отправную точку для тех, кто ищет хороший ORM. Он превосходит простой CRUD, но я бы не стал использовать его для массовых запросов, таких как интеллектуальный анализ данных или вычисление чисел.

К сожалению, мое приложение больше разнообразно (хотя есть и CRUD), поэтому я решил сделать свое собственное. С самого начала я знал, что это будет не так, как другие решения, но это будет достаточно хорошо и даст мне необходимую производительность. Теперь вот действительно замечательная часть: это очень похоже на ваше решение!

Это то, что, я думаю, вы сделали наиболее правильно: вы назвали свои основные убеждения своего рода заявлением о миссии, и эти убеждения верны. Очевидно, я тоже потратил немало времени на размышления об этой проблеме, и ее трудно решить. Но со временем, я думаю, что сообщество программистов лучше поймет это, и мы будем создавать лучшие решения. Слава всем предыдущим усилиям (особенно Hibernate), но я думаю, что мы можем сделать лучше.

Ваше решение лучше устраняет проблему, но решает только ее часть. Я думаю, что многоуровневый подход может дать нам все, что мы хотим. То, что вы придумали / IMO, это базовый уровень. Как вы предположили, я думаю, что этот слой лучше всего автоматически генерировать на основе схемы базы данных. Это должна быть очень простая реляционная объектная модель, которая отображается непосредственно в базе данных и не более. Вы правы в том, что данные сохраняются намного дольше, чем код, поэтому на этом уровне данные должны управлять кодом, а не наоборот. Он будет поддерживать CRUD, а также массовые запросы. Я бы, вероятно, реализовал какой-то кэш L1 на этом уровне.

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

Я открыт для того, чтобы иметь больше слоев, но ключевой момент для меня заключается в том, что, предоставляя несколько точек входа в библиотеку, вы можете выполнить любую потребность. Для тех, кто хочет простое решение CRUD, которое отображается непосредственно на объекты по их выбору, они могут строить на верхнем слое. Для тех, кто ищет что-то более мощное и производительное, но желает нести дополнительную сложность, они могут подключиться к нижнему уровню. Я бы не стал создавать специальный язык запросов, а вместо этого выставил бы объект вашего конструктора запросов для этой цели. А поскольку код является многоуровневым, эта функциональность, естественно, существует без специального сквозного доступа.

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

Дейл Андерсон
источник
Привет Дейл, спасибо за вашу поддержку! Мне нравится ваша фраза о слоях и jOOQ, находящемся на самом нижнем слое, с дальнейшей абстракцией, возможной поверх jOOQ. Это то, что я хочу решить, когда у меня будет достаточно импульса с JOOQ. Взаимодействие с JPA и / или Hibernate явно будет в планах. Как вы говорите, эти инструменты отличаются простотой благодаря абстракции и имеют много функций, которые мне не нужны на моем уровне: транзакции, сеансы, кэши L2 и т. Д. PS: Является ли ваше собственное решение общедоступным? Мне было бы очень интересно!
Лукас Эдер
8

«Там много волшебных пуль и нет недостатка в наивных разработчиках».

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

Квентин-starin
источник
1
Спасибо за ваш отзыв! Вы более подробно изучили мою библиотеку? Я точно пытаюсь "отказаться от", как это называется в вашей статье. jOOQ хочет, чтобы разработчики писали SQL, а не код OR-Mapped. Я пытаюсь добиться того, что Linq делает для .NET, не имея возможности переписать компилятор Java. Поздравляем Microsoft с Linq! И я осмелюсь сказать, что я не наивен, потому что я создал jOOQ после того, как меня не удовлетворил ни EJB 2.0 (довольно давно), ни Hibernate. Именно по причинам, которые вы указали в своей статье. Я попробовал то, что было сделано, и это не соответствовало моим потребностям.
Лукас Эдер
Компания jOOQ хочет, чтобы разработчики использовали ваш Criteria-like API. Это не SQL. Это способ создания SQL, который на самом деле более уродлив и сложен, чем SQL, с очень незначительными, если вообще есть, реальными преимуществами. "q.addCompareCondition (TAuthor.YEAR_OF_BIRTH, 1920, Comparator.GREATER);" Я не вижу ничего действительно отличного от любого другого инструмента генерации класса на таблицу. Что означает, как я уже сказал, есть почти определенная вероятность того, что лучший уже существует. Сгенерированные шаблоном строковые поля даже близко не подходят к тому, что разрешают лямбда-выражения.
Квентин Старин
1
Мне немного сложно понять мотивацию вашего ответа / комментария. Я все еще думаю, что вы не внимательно изучили приведенные мною примеры (вы привели самый первый пример), и ваше сравнение с конкурирующими продуктами мне кажется несколько расплывчатым. Суть моего вопроса состояла в том, чтобы получить конструктивную обратную связь, и я был бы очень признателен. Вы упоминаете «лучшие инструменты» и «лямбда-выражения». Не могли бы вы уточнить? Как jOOQ сравнивается с инструментами, которые вы упомянули? Как лямбда-выражения реализованы в Java 6 - до того, как Oracle сможет добавить их в Java 8? Еще раз спасибо
Лукас Эдер
2

Один из сценариев, который сделает этот вид API хорошо подходящим, - это когда вам нужен независимый от базы данных SQL-компоновщик, который большинство ORM не позволяет вам иметь. Одна большая ситуация, в которой я нуждался в этом, заключается в создании отчетов. Мне нужно было построить SQL объектно-ориентированным способом и собираться запустить этот sql на различных базах данных для тестирования. Hibernate и другие ORM очень зависят от конфигураций, поэтому я ограничиваю свою конструкцию sql так, что я не могу объединить таблицу, в которой ассоциация не существует в xmls. Поскольку в разрабатываемом мной модуле отчетности возможна любая связь, я искал что-то другое. Потом я наткнулся на JOOQ. Это просто решает мою проблему. Мне просто нужен доступ только для чтения, я никогда не сталкивался с болезненными проблемами отладки, как в спящем режиме.

На самом деле я планирую разработать другой способ моделирования данных, а не общий способ POJO, и использовать JOOQ в качестве одного из основ, который является слоем для построения SQL. Итак, помимо JOOQ, я планирую создать более гибкий способ моделирования данных / сущностей с помощью HashMaps. Мой дизайн позволил бы упростить интеграцию внешнего интерфейса и внутреннего интерфейса в одной точке входа, хотя я бы использовал различные уровни для завершения структуры, как и в приведенных выше комментариях. JOOQ действительно сыграет очень хорошую роль, как и в моем собственном проекте, он служит одной из основ или опор.

Так что продолжайте в том же духе, Лукас!

виноградная лоза
источник
1

Если я правильно понимаю ваш инструмент, он отображает Объекты непосредственно в концептуальную среду SQL, а не отображает Объекты, которые реализуют некоторое сопоставление с функциональностью SQL (ORM), почти как абстракция ORM - для большего контроля над компьютерными процессами, чтобы вы могли использовать больше функций SQL ОРМ обычно не дает?

Не уверен, какую проблему вы пытаетесь решить. Поскольку ваш инструмент требует глубоких знаний SQL, люди не будут просто использовать, ну, SQL? Это тот код клея, от которого вы пытаетесь избавиться? Лучшая проверка SQL-запросов с помощью моделирования API вместо простых строк?

Я должен признать, что ваши примеры JOOQ выглядят как LISP-версии SQL. Не то, чтобы это было плохо :), и я вижу, что некоторые продвинутые вещи интересны, но преимущества, которые вы перечисляете, постепенно исчезают по мере того, как вы становитесь все более продвинутыми (более конфигурированными, менее абстрактными, более укоренившимися во внутренней святыне конкретного SQL двигатель и тд)

Одно из предложений, которое мне хотелось бы видеть, что я пропускаю большинство ORM, - это фреймворк, который может иметь дело с объектами нереляционным способом, переводя взаимодействия объектов в любой внутренний интерфейс (SQL, NoSQL, тематические карты, RDF и т. Д.). .) который требует кэширования используемой модели, а не специфики взаимодействий SQL, диалектов и реляционного мышления.

ИМХО, конечно. :)

AlexanderJohannesen
источник
Привет, спасибо за ваш отзыв. Вы правильно поняли. Как сказал qstarin, я пытаюсь удалить букву «О» из ORM и остаться в отношениях. Почему не простой SQL? Вы имеете в виду JDBC? Вы когда-нибудь запрашивали в своей базе данных 5 вложенных выборок и несколько объединений, аналитических функций с JDBC? Синтаксические ошибки, несоответствие привязок и т. Д. К сожалению, jOOQ не может быть правильным инструментом для вас, потому что нет возможности сопоставить ЛЮБУЮ модель с объектами. И я не хочу этого. JOOQ ДОЛЖЕН быть реляционным. Для тех разработчиков, которые предпочитают такой способ мышления. Для других я рекомендую JPA .. Или Linq, если вы делаете .NET
Лукас Эдер