Есть ли смысл работать БД без ORM, только JDBC

 
 
 
Сообщения:806
На последнем месте работы у нас была самомдельная приспособа для работы с БД, generic DAO реализующий CRUD для наших сущностей. Возможности средства были сильно ограничены, мне было тяжело и не интресно с ним работать. Самое неприятное - делать какскадность и eager fetch для развестистых, но редкоизменяемых моделей. Вообщем я прочувствовал идею "никаких тяжелых библиотек в проекте" и не хочу повторять этот опыт.

Сейчас откликнулся на вакансию, начал делать тестовое задание (типичный справочник, список объектов, просмотр, редактирование) и уточняющим вопросом выяснил, что DAO нужно сделать без ОРМ, чисто на JDBC. Желания реализовывать CRUD самостоятельно у меня совершенно нет.

Вообщем интересно узнать, как вы считаете, есть ли смысл НЕ использовать ORM библиотеки?
 
 
Сообщения:48
Теоретически, можно представить такой use-case, в котором overhead использования ORM будет значимым и, как следствие, нежелательным.
Второй момент - желание контролировать все взаимодействие с базой (из разряда "вот здесь я хочу грузить все связи, а здесь - нет. А здесь хочу грузить те и те").
Ну и завершающий - jdbc входит в стек java SE и, в принципе, разработчики должны ее знать и уметь с ней работать по умолчанию.
Из своего же опыта могу сказать, что мне было комфортнее работать с Spring JDBC, чем с тем же Hibernate.
 
 
Сообщения:2361
pjotar:
Вообщем интересно узнать, как вы считаете, есть ли смысл НЕ использовать ORM библиотеки?

Конечно есть, например ORM банально не натянешь на уже существующую легаси базу, которая писалась без рассчета на ORM. Конечно писать на чистом JDBC это моветон, тот кто выставляет такие требования к тестовому заданию, скорее всего просто хочет проверить насколько хорошо соискатель знает стандарт JDBC. Что касается не использовать ORM для продакшена, то очень многие так и поступают, но используют конечно не голый JDBC, а удобные типобезопасные обёртки с автоматической кодогенерацией, самая популярная из мне известных это JOOQ. С одной стороны это не полноценные ORM, и они избавленны от подводных камней и негибкости которые присущи тяжелым ORM, с другой стороны то что на самом деле нужно программисту это автоматизация рутины при написании запросов, и например JOOQ с этой целью прекрасно справляется, при этом сохраняя типобезопасность на высшем уровне - уровне компилятора.
 
 
Сообщения:28
Можно хоть все на хранимых процедурах сделать и дергать их по JDBC. Все будет прекрасно работать на БД, за исключением корректной обработки транзакций...мой совет: делайте проще, а не как распиарено:)) P.S. видел массу проектов куда засовывают Spring, JPA реализации и прочих монстров, только ради этих монстров, а по сути они там вообще не нужны
 
 
Сообщения:806
izluchatel:
делайте проще, а не как распиарено:))

В тестовом задании нужно сделать UI для CRUD операций. Слой DAO реализуется проще всего как-раз на JPA, например одной строкой SpringData.

Agny:
желание контролировать все взаимодействие с базой (из разряда "вот здесь я хочу грузить все связи, а здесь - нет. А здесь хочу грузить те и те").

В одном проекте были расставлены указания хибернейту в запросах, какие связи вытаскивать eager. Правда это было сделано скорее из-за лени расставлять eager и lazy в модели :-)

Agny:
jdbc входит в стек java SE и, в принципе, разработчики должны ее знать и уметь с ней работать по умолчанию

Vermut:
тот кто выставляет такие требования к тестовому заданию, скорее всего просто хочет проверить насколько хорошо соискатель знает стандарт JDBC

Хотелось бы верить. Я не против в специфичных случаях работать напрямую с JDBC. Тогда и тестовое задание должно быть интересное. В этом проекте мне кажется просто делают кучу работы с JDBC на пустом месте :-(
 
 
Сообщения:786
Quote:
Можно хоть все на хранимых процедурах сделать и дергать их по JDBC. Все будет прекрасно работать на БД


О, какой привет из 90ых! :D Ещё и на Delphi десктопный клиент налабать и лить ностальгические слёзы!
Советчики ппц)

ORM вообще и hibernate в частности как правило боятся и не любят те, кто его не смог освоить нормально и плохо понимает, как оно устроено.
Для 90% проектов это идеальный путь для взаимодействия с базой.
 
 
Сообщения:798
Есть еще оракловские пользовательские типы. Они могут эффективнее ОРМ работать - вся иерархия некоторой части модели хранится в объекте Oracle. И вот здесь ничего кроме JDBC не надо, просто смысла нет одно объектное поле в таблице мэпить на Java класс.

Нет ничего проще, чем заблудиться в иллюзиях, нет ничего сложнее, чем освободиться от них.
 
 
Сообщения:142
а если еще на оракловый тип навернуть гибернейтовский, да еще и конвертер на поле, то можно один раз загрузив / сохранив какой-нибудь объект ради одного поля, озадачить сервак на пару-тройку секунд! ^_^

 
 
Сообщения:259
Роман Осипов:
Есть еще оракловские пользовательские типы.

Как-то пару-тройку лет назад игрался с Оракловыми типами - чисто в SQL, хотел посмотреть как будет выглядеть в таком виде одна из своих реляционных БД. Правда, приложение с этой базой не связывал, так и осталось на уровне экспериментов. Но впечатления остались положительные: работа с объектами на уровне СУБД.

Вот так и не понял, почему эта фича РСУБД осталась не востребованной, хотя в том же Оракле существует уже давно (в 9-ке точно была, в 8-ке - не помню).

"Любая техническая система должна быть идиотоустойчивой" (с) один из университетских преподов
 
 
Сообщения:806
Сейчас получил проект в котором половина работы - импортировать ФИАС, а это 26GB XML. Таки настроил Hibernate на производительность, при которой больше нет мыслей, что чистый jdbc был бы быстрее. За пару часов заливает в БД все 46 миллионов домов России :-)
 
Модераторы:Нет
Сейчас эту тему просматривают:Нет