Java - [закрытые] альтернативы JDBC

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

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

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

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

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

Спящий режим, конечно. Популярно, есть даже версия .NET.

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

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

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

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

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

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

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

Одним из таких фреймворков, который довольно прост в использовании, является Spring JdbcTemplate.

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

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

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

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

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

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

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

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

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

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

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

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

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

Ebean ORM - еще одна альтернатива http://ebean-orm.github.io/

Ebean использует JPA Annotations для Mapping, но он спроектирован как бессеансовый. Это означает, что у вас нет концепций attached/detached и вы не персистируете/сливаете/промываете - вы просто сохраняете() свои бобы.

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

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

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

http://www.mybatis.org