JDBC VS Hibernate

Ответ 1

Проблемы с ответами, перечисленные выше:

1. Hibernate не может подключиться к базе данных "Существующий". Он всегда пытается создать свой собственный.

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

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

Hibernate имеет настраиваемый кеш, поэтому это тоже не проблема.

3. Мы никогда не хотели бы приводить "таблицу создания работы" к java-коду. Мы создаем таблицы вручную, всегда.

Нет проблем. См. Стр .1 выше. Furthemore существует несколько удобных библиотек для создания и обновления косвенных таблиц (например, liquibase), которые можно использовать в паре с спящим режимом.

4. Возможно, нам придется использовать очень длинные и сложные SQL-операторы. В прошлый раз мы использовали инструкцию с более чем 150 строками, объединив более 20 таблиц. Мы сомневаемся, столкнемся ли мы с проблемами в этом, когда дело доходит до спящего режима.

Вы всегда можете использовать прямые вызовы JDBC и вызывать собственные SQL-запросы с помощью спящего режима, если он не выбран.

5. Наш код SQL хорош и стандартен. Сгенерированный спящий код, похоже, немного грязный для нас.

Опять же, если вам нужно вызывать некоторую логику, сложный код SQL вместо спящего режима, сгенерированный автоматически - вы можете это сделать.

6. Мы всегда используем MySQL. Никогда не используйте какую-либо другую БД.

Не проблема вообще. Hibernate имеет специальную поддержку диалогов MySQL: org.hibernate.dialect.MySQLDialect.

7. Созданное приложение требует максимальной безопасности, связанной с медицинскими. Если по крайней мере одна запись данных просочилась, мы закончили.

Проблемы безопасности не связаны с методами ORM. Hibernate - это просто логичный и удобный объектно-ориентированный уровень между чистыми вызовами JDBC базы данных и инструментами программистов. Это никак не влияет на общую чистую безопасность.

Ответ 2

Hibernate - отличный инструмент, и вы найдете множество документации, книг и статей блога об этом.

Я рассмотрю все ваши проблемы:

Hibernate не может соединиться с "существующей" базой данных. Он всегда пытается создать свой собственный.

Hibernate должен использовать отдельную процедуру управления схемой базы данных даже для интеграционного тестирования. Вам следует использовать инструмент инкрементного управления версиями, например FlywayDB, для управления изменениями схемы.

К нашей базе данных может обращаться одно и то же приложение, которое находится на разных платформах (облако, сервер, VPS, персональный компьютер). Hibernate может создавать проблемы из-за кеширования в этой ситуации.

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

Мы никогда не хотели отдавать "работу по созданию таблиц" Java-коду. Мы создаем таблицы вручную, всегда.

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

Возможно, нам придется использовать очень длинные и сложные операторы SQL. В прошлый раз мы использовали оператор с более чем 150 строками, объединяющими более 20 таблиц. Мы сомневаемся, столкнемся ли мы с проблемами в этом, когда речь заходит о Hibernate.

Hibernate отлично подходит для операций записи и управления параллелизмом. Вам все еще нужно использовать собственный SQL для сложных запросов (оконные функции, CTE). Но Hibernate позволяет выполнять собственные запросы.

Наш SQL-код хорош и стандартен. Сгенерированный Hibernate код кажется нам немного грязным.

Вам не нужно, и вы, вероятно, не должны использовать утилиту hbmdll в любом случае.

Мы всегда используем MySQL. Никогда не используйте никакие другие БД.

Это даже лучше. Поэтому вы можете использовать предварительные собственные запросы, не заботясь о проблемах переносимости базы данных.

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

Hibernate не мешает вам защитить вашу базу данных или код доступа к данным. Вы все еще можете использовать меры безопасности базы данных с Hibernate тоже. Вы даже можете использовать Jasypt, чтобы включить все виды функций, связанных с безопасностью:

• расширенное хеширование паролей
• двустороннее шифрование

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

Все они поддерживаются Hibernate. Помимо соглашений JPA, Hibernate также предлагает определенное сопоставление для любого экзотического сопоставления.

Мы решили попробовать hibernate, потому что некоторые люди утверждают: "Вы разработчики программного обеспечения? Вы используете уже мертвый JDBC !!."

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

Ответ 3

Использование простого старого JDBC не означает, что вам не хватает ИТ-индустрии, но Hibernate также использует JDBC в базовом слое.

Какие преимущества дает нам то, что мы должны искать.

1.) Cache Механизм.

2.) Управление sessions, transactions и т.д.

3.) Уменьшите усилия при написании запросов, дополнительных утилит спящего режима, таких как Query API, Criteria API, HQL

Вопросы, которые вы подняли, более или менее описаны в Hibernate docs.

Также есть много возможностей для кэширования. ehcache, infinispan, зависит от сервера, который мы развертываем, JBOSS, Weblogic, Tomcat и т.д. ++, таких как облако, распределенный кеш и т.д.

Hibernate по-прежнему предоставляет вам возможность автоматически отключать создание схемы и указывать на созданную вами.

Ответ 4

Вот быстрые ответы, которые я знаю

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

Если у вас нет модели твердого объекта, я бы сказал, что Hibernate - это страшный выбор.

2) По мере доступа к базе данных из разных приложений вы можете поддерживать блокировки. С другой стороны, вы можете отключить кеширование как выполненное здесь.

3) Вы можете создавать таблицы вручную и подключаться к нему с помощью файла .hbm.xml.

4) Вы можете использовать любой тип запроса в спящем режиме, как простые критерии запросов SQL.

5) Если вы хотите, вы можете напрямую использовать код SQL в Hibernate. Другой вариант - использовать критерии.

6) Hibernate НЕ является специфичным для БД. Вы можете перейти на любую базу данных и связать ее с гибернацией.

7) Использование блокировок и предоставление прав в базе данных позволяет поддерживать безопасность.

8) Согласился, что внешние ключи беспорядочны в спящем режиме Если вы не справляетесь с ней хорошо. Поэтому используйте подход OO и хорошо поддерживайте каскады, тогда Hibernate будет хорошим выбором.