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

Постоянство в 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, и чего, по вашему мнению, не хватает? Где я ошибся, концептуально или практически?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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