Що б ви думали про новий інструмент збереження Java, це насправді не ORM? [зачинено]

Наполегливість на Яві

Протягом останніх років я збирав досвід у галузі стійкої абстракції на Java, використовуючи такі поняття, як EJB 2.0, Hibernate, JPA та домашні вироби. Мені здавалося, що у мене крута крива навчання та багато складності. Крім того, як великий шанувальник SQL, я також вважав, що багато моделей абстракції забезпечують занадто велику абстракцію над SQL, створюючи такі поняття, як "критерії", "предикати", "обмеження", які є дуже хорошими поняттями, але не є SQL.

Загальна ідея стійкості абстракції на Java, здається, базується на об'єктно-реляційній моделі, де RDBMS якось узгоджується зі світом OO. Дебати щодо ОРМ завжди були емоційними, оскільки, здається, не існує єдиного рішення, яке підходить усім - якщо таке рішення навіть може існувати.

jOOQ

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

• Мова домену, заснована на SQL
• Генерація вихідного коду відображає основні схеми бази даних на Java
• Підтримка багатьох RDBMS

Додавання деяких функцій, які мають декілька сучасних інструментів збереження (виправте мене, якщо я помиляюся):

• Підтримка складних SQL - об'єднань, вкладених вибірок, самостійних приєднань, псевдоніму, випадок, арифметичні вирази
• Підтримка нестандартних SQL - збережених процедур, UDT, ENUMS, нативних функцій, аналітичних функцій

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

Питання

Тепер, сказавши, що я великий шанувальник SQL, мені цікаво, чи поділяться інші розробники моїм захопленням jOOQ (або Linq). Чи такий підхід до стійкої абстракції є життєздатним? Які переваги / недоліки ви можете бачити? Як я міг покращити jOOQ, а чого не вистачає на вашу думку? Де я помилився, концептуально чи практично?

Критичні, але конструктивні відповіді високо оцінені

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

Я думаю, що ви на правильному шляху і маєте продовжувати своє рішення. Деякі попередні критики надто суворі, але деякі вагомі моменти.

Я теж довго і наполегливо шукав повнофункціональне рішення ORM, яке б відповідало моїм потребам, але кожне рішення, на яке я звернувся, виявилося коротким. У кожного є свої плюси і мінуси, але ніхто насправді не робив усе, що я хотів. Я погоджуюся з вашою критикою цих рішень, а саме - вони, як правило, складні та мають круту криву навчання.

Топ-претендент повинен був стати фактичним стандартом, взимку. Це повнофункціональний, надійний і добре перевірений. Я її поважаю і ціную за те, що є. Тепер, ризикуючи образити половину спільноти програмування, я також повинен сказати, що це роздутий і складний фрагмент коду, що не виконує функції. Я витратив неабияку кількість часу, ковзаючи в її надрах, намагаючись налагодити і зрозуміти це, і мене не вразило побачене. Сказавши це, я все-таки рекомендую це як вихідний пункт для тих, хто шукає хорошого ORM. Він чудовий у простому CRUD, але я б не використовував його для виконання масових запитів, таких як обробка даних або обробка чисел.

На жаль, у моїй програмі більше різноманітності за кількістю скорочень (хоча є і деякі CRUD), тож я вирішив запустити свою власну. Я з самого початку знав, що це буде нижчим рівнем порівняно з іншими рішеннями там, але це було б досить добре і дало б мені потрібну продуктивність. Тепер ось справді велика частина: це дуже схоже на ваше рішення!

Це те, що я вважаю, що ви зробили найбільш правильно: ви висловили свої основні переконання як своєрідну заяву про місію, і ці переконання є правильними. Я, очевидно, витратив досить багато часу на роздуми над цією проблемою, і її важко вирішити. Але з часом я думаю, що програмістська спільнота зрозуміє це краще, і ми створимо кращі рішення. Кудо всім попереднім зусиллям (особливо в сплячому режимі), але я думаю, що ми можемо зробити краще.

Ваше рішення краще уточнює проблему, але воно вирішує лише її частину. Я думаю, що шаруватий підхід може дати нам все, що ми хочемо. Те, що ви придумали / IMO, - це основний шар. Як ви вже запропонували, я думаю, що цей шар найкраще автоматично генерувати на основі схеми бази даних. Це повинна бути дуже проста реляційна модель об'єкта, яка відображається безпосередньо на базі даних і не більше. Ви праві, що дані зберігаються набагато довше, ніж код, тому на цьому рівні дані повинні керувати кодом, а не навпаки. Він підтримує CRUD, а також ефективний масовий запит. Я, мабуть, реалізував би якийсь кеш L1 на цьому шарі.

Однак, чим відрізняються інші рішення ORM, це здатність визначати ваші об'єкти таким чином, що не так сильно залежить від фактичної структури базової бази даних. Для цієї функціональності я створив би ще один шар. За необхідності цей шар стає більш абстрактним, сподіваємось, простішим (за рахунок втраченої функціональності) та будується на попередньому шарі. Він може використовувати кеш L2.

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

Я думаю, що ви розумієте простір і не винаходите колесо, а навпаки, зайняли трохи іншу нішу. І, чесно кажучи, це колесо, яке в будь-якому разі могло б вдосконалити. Ви стикаєтеся зі складною битвою, яка суперечить енергетичним центрам минулого, але якщо ваше рішення добре, і я думаю, що воно рухається саме так, то воно здобуде популярність за власними заслугами.

"Там багато магічних куль, і наївних розробників немає."

Без образи, здається, ви не зовсім розумієте, що зроблено в цьому просторі, і тому вигадуєте деякі колеса - досвід підкаже нам усе, що колеса, які ви винаходите, при цьому акуратні та веселі, швидше за все, не будуть майже такими, як гарні чи корисні, як добре вишукані колеса, які вже доступні.

Один зі сценаріїв, який би зробив цей API дуже підходящим, коли вам потрібен конструктор SQL-агресивних баз даних, який більшість ORM не дозволяє вам мати. Одна велика ситуація, коли мені це було потрібно - це створення звітів. Мені потрібно було побудувати SQL об'єктно-орієнтованим способом і збираюся запускати цю sql на різних базах даних для тестування. Зимова сплячка та інші ORM дуже залежать від конфігурацій, таким чином обмежуючи мою конструкцію sql таким чином, що я не можу поєднувати таблицю там, де асоціація не існує в xmls. Оскільки в модулі звітів, який я розробляю, можлива будь-яка асоціація, я шукав щось інше. Потім я натрапив на JOOQ. Це просто вирішує мою проблему. Мені просто потрібен доступ лише для читання, ніколи не стикаюся з болісними проблемами налагодження, як у сплячому режимі.

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

Тож продовжуйте гарну роботу луки!

Якщо я правильно розумію ваш інструмент, він відображає об'єкти безпосередньо в концептуальній структурі SQL, а не відображає об'єкти, які реалізують деяке відображення у функціональність SQL (ORM), майже як ORM - абстракція для більшого видовищного контролю, щоб ви могли використовувати більше функцій SQL ORM зазвичай не дасть вам?

Не впевнений, яку проблему ви намагаєтеся вирішити. Оскільки ваш інструмент вимагає поглибленого знання SQL, чи не просто люди користуватимуться, ну, SQL? Це клей-код, якого ви намагаєтеся позбутися? Краща перевірка запитів SQL за допомогою моделювання API замість простих рядків?

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

Одне із пропозицій, я хотів би побачити, що я пропускаю в більшості ORM - це структура, яка може обробляти об'єкти нереляційним способом, переводячи взаємодії об'єктів у будь-який сервіс (SQL, NoSQL, Maps Topic, RDF тощо). .), що вимагає кешування використовуваної моделі, а не специфіки взаємодій SQL, діалектів та реляційного мислення.

ІМХО, звичайно. :)