Java - альтернативы JDBC

Question

Это всего лишь теоретический вопрос.

Я использую JDBC с моими Java-приложениями для использования базы данных (выберите, вставьте, обновите, удалите или что-то еще). Я делаю «вручную» Java-классы, которые будут содержать данные из таблиц DB (атрибут = столбец db). Затем я делаю запросы (ResultSet) и заполняю эти классы данными. Я не уверен, если это правильный путь.

Но я много читал о JDO и других решениях настойчивости.

Может кто-нибудь, пожалуйста, порекомендуйте наилучшие использованные альтернативы JDBC, основываясь на их опыте?

Я также хотел бы узнать преимущества JDO над JDBC (простыми словами).

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

Благодаря

Answer 1

История персистенции базы данных в Java уже давно и полна изгибов и поворотов:

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

• EJB 1.0 CMP Entity Beans был первым попробовать на более высоком уровне API и был успешно принят крупными поставщиками Java EE (BEA, IBM), но не пользователями. Сущность Бобы были слишком сложными и имели слишком много накладных расходов (понять, плохая производительность). FAIL!

• EJB 2.0 CMP пытались уменьшить некоторые сложности Entity Beans с введением локальных интерфейсов, но большинство сложности остались. EJB 2.0 также не обладал переносимостью (поскольку объектно-реляционное сопоставление не было частью спецификации, и дескриптор развертывания был таким образом проприетарным). FAIL!

• Потом JDO который является хранилища данных агностик стандарт для хранения объектов (можно использовать с реляционными базами данных, OODBMS, XML, Excel, LDAP). Но, хотя существует несколько версий с открытым исходным кодом, и в то время как JDO был принят небольшими независимыми поставщиками (в основном поставщики OODBMS надеются, что пользователи JDO будут позже переключаться со своего хранилища данных RDBMS на OODBMS, но этого, очевидно, никогда не было), он не смог принятой крупными игроками и пользователями Java EE (из-за плетения, которая была боль во время разработки и пугала некоторых клиентов, странного API запросов, быть слишком абстрактными). Итак, хотя сам стандарт не мертв, я считаю его провалом. FAIL!

• И действительно, несмотря на существование двух стандартов, собственные API-интерфейсы, как Toplink, старый плеер, или Hibernate были предпочитаемых пользователями через EJB CMP и JDO для объекта персистентности реляционной базы данных (конкуренция между стандарты, нечеткое позиционирование JDO, более ранняя неудача CMP и плохой маркетинг являются частью ответственности в этом, я считаю), а Hibernate фактически стал стандартом де-факто в этой области (это отличная открытая структура). УСПЕХ!

• Тогда ВС поняли, что они должны были упростить вещи (и вообще в целом Java EE), и они сделали это в Java EE 5 с JPA, то Java Persistence API, который является частью EJB 3.0 и является новый стандарт для устойчивости объекта к реляционной базе данных. JPA объединяет EJB 2 CMP, JDO, Hibernate и TopLink API/продукты и, кажется, преуспевает там, где EJB CMP и JDO не удалось (простота использования и принятия). УСПЕХ!

Резюмируя, стандарт Java для персистенции базы данных является JPA и должна быть предпочтительнее других проприетарных API (с помощью реализации Hibernate по JPA это хорошо, но использовать JPA API), если ОРМ не является то, что вы необходимость. Он обеспечивает API более высокого уровня, чем JDBC, и предназначен для того, чтобы сэкономить вам много ручной работы (это упрощено, но это идея).

Answer 2

Я могу рекомендовать Hibernate. Он широко используется (и по уважительным причинам), и тот факт, что спецификация Java Persistence API была проведена главным дизайнером Hibernate, гарантирует, что она будет в обозримом будущем :-) Если для вас важна мобильность и нейтральность поставщиков, вы может использовать его через JPA, поэтому в будущем вы можете легко переключиться на другую реализацию JPA.

Не имея личного опыта работы с JDO, я не могу сравнить эти два. Однако преимущества Hibernate (или ORM в целом) на первый взгляд кажутся почти такими же, как то, что указано на JDO page. Для меня самые важные моменты:

• DB нейтральность: Hibernate поддерживает несколько диалектов SQL в фоновом режиме, переключение между БД так же легко, как изменение одну строку в конфигурации
• производительность: ленивая выборку данных по умолчанию, и намного больше оптимизаций происходит под капотом, которые вам нужно будет обрабатывать вручную с помощью JDBC
• вы можете сосредоточиться на своей модели домена и дизайне OO вместо проблем с более низким уровнем БД (но вы можете, конечно, точно настроить DML и DDL, если вы этого хотите)

Один из потенциальных недостатков (в основном, инструментов ORM) заключается в том, что он не подходит для пакетной обработки. Если вам нужно обновить 1 миллион строк в вашей таблице, ORM по умолчанию никогда не будет выполнять, а также пакетное обновление JDBC или хранимую процедуру. Тем не менее, Hibernate может включать хранимые процедуры и в некоторой степени поддерживает пакетную обработку (я пока не знаком с этим, поэтому я не могу сказать, соответствует ли это задаче в этом отношении по сравнению с JDBC, но, судя по тому, что я знаю, возможно, да). Поэтому, если ваше приложение требует пакетной обработки, но в основном имеет дело с отдельными объектами, Hibernate все еще может работать. Если он преимущественно выполняет пакетную обработку, возможно, JDBC - лучший выбор.

Answer 3

JDO строит технологию JDBC. Аналогично, Hibernate по-прежнему требует JDBC. JDBC - базовая спецификация Java для подключения к базе данных.

Это означает, что JDBC даст вам больший контроль, но для этого требуется больше сантехники.

JDO обеспечивает более высокие абстракции и меньше сантехники, поскольку сложность скрыта.

Если вы задаете этот вопрос, я предполагаю, что вы не знакомы с JDBC. Я думаю, что для того, чтобы эффективно использовать JDO, Hibernate или любой другой более высокий инструмент абстракции, требуется базовое понимание JDBC. В противном случае вы можете столкнуться с сценарием, в котором инструменты ORM демонстрируют поведение, которое вы не можете понять.

Учебник Java Sun на их веб-сайте представляет собой достойный вводный материал, который проходит через JDBC. http://java.sun.com/docs/books/tutorial/jdbc/.

Answer 4

Hibernate, конечно. Это популярно, есть даже версия .NET.

Кроме того, спящий режим может быть легко интегрирован с пружинным каркасом.

И это будет в основном соответствовать любым потребностям разработчиков.

Answer 5

Новая и захватывающая альтернатива - GORM, которая является реализацией ORM от Grails. Теперь можно использовать автономно. Под капотом он использует Hibernate, но дает хороший слой сверху с крутыми динамическими искателями и т. Д.

Answer 6

Hibernate требует, чтобы у вас была объектная модель для сопоставления схемы. Если вы все еще думаете только о реляционных схемах и SQL, возможно, Hibernate не для вас.

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

Другой вариант - iBatis. Если JDBC является сырым SQL, а Hibernate - ORM, iBatis можно рассматривать как нечто между двумя. Это дает вам больше контроля над SQL, который выполняется.

Answer 7

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

Обратите внимание, что для их работы существуют предположения, которые вам необходимо соблюдать. Обычно они разумны и довольно просты в работе, особенно если вы начинаете со стороны Java, а не должны работать с существующими таблицами базы данных.

JDO - это конвергенция различных проектов в одном стандарте Sun и тот, который я предлагаю вам изучить. Для реализации выберите одну из предложенных вами IDE в своих различных мастерах.

Answer 8

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

Answer 9

Если вы хотите написать SQL самостоятельно и не хотите ORM, вы все равно можете воспользоваться некоторыми фреймворками, которые скрывают всю утомительную обработку соединения (try-catch-finally). В конце концов вы забудете закрыть соединение ...

Один такой каркас, который довольно прост в использовании, - Spring JdbcTemplate.

Answer 10

Существует также крутящий момент (http://db.apache.org/torque/), который я лично предпочитаю, потому что он проще и делает именно то, что мне нужно.

С крутящим моментом я могу определить базу данных с mysql (ну, я использую Postgresql, но Mysql поддерживается), и Torque может затем запросить базу данных, а затем сгенерировать классы java для каждой таблицы в базе данных. С помощью Torque вы можете запросить базу данных и вернуть Java-объекты правильного типа.

Он поддерживает, где предложения (либо с объектом Criteria, либо вы можете написать sql самостоятельно) и присоединяется.

Он также поддерживает внешние ключи, поэтому, если у вас есть таблица User и таблица House, где пользователь может владеть 0 или более домами, на объекте пользователя будет создан метод getHouses(), который предоставит вам список Объектов Дома принадлежит пользователю.

Чтобы получить первый вид кода, который вы можете написать, взгляните на http://db.apache.org/torque/releases/torque-3.3/tutorial/step5.html, который содержит примеры, показывающие, как загружать/сохранять/запрашивать данные с крутящим моментом. (Все классы, используемые в этом примере, автоматически генерируются на основе определения базы данных).

Answer 11

Ebean ОРМ является еще одной альтернативой http://ebean-orm.github.io/

Ebean использует JPA Аннотации для карт, но она спроектирована, чтобы быть sessionless. Это означает, что у вас нет прикрепленных/отключенных концепций, и вы не сохраняете/слияния/флеша - вы просто просто сохраняете() ваши бобы.

• Я бы ожидать Ebean гораздо проще в использовании, чем Hibernate, JPA или JDO

Так что если вы ищете мощный альтернативный подход к JDO или JPA вы могли бы посмотреть на Ebean ,

Answer 12

Посмотрите на MyBatis. Часто упускается из виду, но отлично подходит для сложных запросов только для чтения, используя проприетарные функции вашей СУБД.

http://www.mybatis.org

Answer 13

Вот как это происходит с Java Persistence. Вы только что узнали Java, теперь вы хотите сохранить некоторые записи, вы узнаете JDBC. Вы счастливы, что теперь можете сохранить свои данные в базе данных. Затем вы решите написать немного большее приложение. Вы понимаете, что стало утомительно пытаться, ловить, открывать соединение, закрывать соединение, передавать данные из результатов в ваш bean ... Итак, вы думаете, что должен быть более простой способ. В java всегда есть альтернатива. Таким образом, вы делаете некоторые поисковые запросы, и через некоторое время вы обнаружите ORM и, скорее всего, спящий режим. Вы так вышли, что вам теперь не нужно думать о связях. Ваши таблицы создаются автоматически. Вы можете двигаться очень быстро. Затем вы решаете провести действительно большой проект, изначально вы двигаетесь очень быстро, и у вас есть все операции на руле. Требования продолжаются, а затем в один прекрасный день вы окажетесь в углу. Вы пытаетесь сохранить, но не каскадируете на объекты. Что-то сделано, как описано в книгах, которые вы прочитали. Вы не знаете, что делать, потому что вы не писали библиотеки спящего режима. Вы хотите, чтобы вы сами написали SQL. Теперь пришло время снова переосмыслить ... По мере того, как вы созреваете, вы понимаете, что лучший способ взаимодействия с базой данных - через SQL. Вы также понимаете, что некоторые инструменты заставляют вас начинать очень быстро, но они не могут длиться долго. Это моя история. Я сейчас очень рад ibatis/User.

Answer 14

Вот как это происходит с сохранением Java. Вы только что узнали Java, теперь вы хотите сохранить некоторые записи, вы узнаете JDBC. Вы счастливы, что теперь можете сохранить свои данные в базе данных. Затем вы решите написать немного большее приложение. Вы понимаете, что стало утомительно пытаться, ловить, открывать соединение, закрывать соединение, передавать данные из результатов в ваш bean ... Итак, вы думаете, что должен быть более простой способ. В java всегда есть альтернатива.Таким образом, вы делаете некоторые поисковые запросы, и через некоторое время вы обнаружите ORM и, скорее всего, спящий режим. Вы так вышли, что вам теперь не нужно думать о связях. Ваши таблицы создаются автоматически. Вы можете двигаться очень быстро. Затем вы решаете провести действительно большой проект, изначально вы двигаетесь очень быстро, и у вас есть все операции на руле.

Answer 15

JPA/Hibernate - популярный выбор для ORM. Он может предоставить вам практически любую функцию ORM, которая вам нужна. Кривая обучения может быть крутой для тех, у кого есть основные потребности ORM.

Существует множество альтернатив JPA, которые обеспечивают ORM с меньшей сложностью для разработчиков с основными требованиями ORM. Запрос SourceForge, например: http://sourceforge.net/directory/language:java/?q=ORM

Я неравнодушен к моему решению, Sormula: sourceforge или bitbucket. Sormula была разработана для минимизации сложности при обеспечении базовой ORM.

Answer 16

Используйте спящий режим в качестве отдельного JAR-файла, а затем распространяйте его на различные веб-приложения. Это лучшее решение. Вы должны создать свои классы, интерфейсы, континуты, чтобы сделать абстрактный шаблон DAO. Пока у вас есть правильные сущности и сопоставления. Вам нужно будет работать только с объектами (сущностями), а не с HSQL.