Когда использовать Hibernate/JPA/Toplink?
https://stackoverflow.com/questions/122571
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Сейчас я делаю очень простой сайт - около 5 страниц.Вопрос в том, является ли это излишним и стоит ли тратить время на интеграцию какого-либо решения для сопоставления базы данных, или было бы лучше просто использовать старый добрый JNDI.У меня будет около дюжины вещей, которые мне нужно будет прочитать/записать из базы данных.Думаю, у меня есть базовое представление об этих технологиях, но все равно потребуется много ссылок на документацию.Кто-нибудь еще сталкивался с таким решением раньше?
РЕДАКТИРОВАТЬ:Извините, мне следовало указать JNDI для поиска соединения с БД и JDBC для выполнения операций.
Решение
Короткий ответ:Это зависит от сложности, которую вы хотите поддерживать.
Длинный ответ:
Прежде всего, ORM (реляционное отображение объектов — отображение базы данных, как вы это называете —) и JNDI (Именование Java и интерфейсы каталогов) — это две разные вещи.
Первый, как вы уже знаете, используется для сопоставления таблиц базы данных с классами и объектами.Второе — предоставить механизм поиска ресурсов, это могут быть источники данных, Ejb, очереди или другие.
Возможно, вы имеете в виду «JDBC».
Теперь что касается вашего вопроса:Если бы это было так просто, возможно, не было бы необходимости реализовывать ORM.Числовых таблиц будет максимум 5–10, а операции, я думаю, очень простые.
Вероятно, будет достаточно использовать простой JDBC.
Если вы используете шаблон DAO, вы можете изменить его позже для поддержки стратегии ORM, если это необходимо.
Так:Допустим, у вас есть таблица «Сотрудники».
Вы создаете файл «Сотрудник.java» со всеми полями БД вручную (это не должно занять слишком много времени) и файл «СотрудникДаО.java» с такими методами, как:
+findById( id ): Employee
+insert( Employee )
+update( Employee )
+delete( Employee )
+findAll():List<Employee>
И реализация довольно проста:
select * from employee where id = ?
insert into employee ( bla, bla, bla ) values ( ? , ? , ? )
update etc. etc
Когда (и если) ваше приложение становится слишком сложным, вы можете изменить реализацию DAO.Например, в методе «select» вы меняете код, чтобы использовать объект ORM, выполняющий операцию.
public Employee selectById( int id ) {
// Commenting out the previous implementation...
// String query = select * from employee where id = ?
// execute( query )
// Using the ORM solution
Session session = getSession();
Employee e = ( Employee ) session.get( Employee.clas, id );
return e;
}
Это всего лишь пример: в реальной жизни вы можете позволить абстрактной фабрике создать ORM DAO, но это оффтоп.Дело в том, что вы можете начать с простого и, используя шаблоны проектирования, при необходимости изменить реализацию позже.
Конечно, если вы хотите изучить технологию, вы можете начать сразу даже с одного стола.
Выбор того или иного решения (то есть решения ORM) в основном зависит от используемой вами технологии.Например, для JBoss или других продуктов с открытым исходным кодом Hibernate отлично подходит.Это открытый исходный код, есть много ресурсов, на которых можно учиться.Но если вы используете что-то, что уже имеет Toplink (например, сервер приложений Oracle) или если база уже построена на Toplink, вам следует оставаться с этой платформой.
Между прочим, с тех пор как Oracle купила BEA, они заявили, что заменяют Kodo (инфраструктуру сохранения веб-логики) на toplink в теперь называемом «сервере приложений Oracle Weblogic».
Я оставляю вам несколько ресурсов, где вы можете получить дополнительную информацию об этом:
В этой книге «Шаблоны архитектуры корпоративных приложений» Мартин Фаулер объясняет, где использовать то или иное, вот каталог.Взгляните на архитектурные шаблоны источников данных и их сравнение.Объектно-реляционные модели поведения:
DAO (Объект доступа к данным) является частью основного каталога шаблонов J2EE:
Это начальное руководство по Hibernate:
Официальная страница Топлинк:
Наконец, я «думаю», что хорошая идея JPA заключается в том, что в последнее время вы можете сменить поставщика.
Начните с простого, а затем развивайтесь.
Надеюсь, это поможет.
Другие советы
Кажется, что это было бы излишним для очень простого приложения, особенно если вы не планируете когда-либо расширять его.Тем не менее, кажется, что стоит использовать их с этим простым приложением, чтобы вы лучше понимали, как они работают, и в следующий раз у вас будет что-то, что может их использовать.
Вы имеете в виду старый добрый JDBC?Небольшой проект может стать хорошей возможностью освоить одну из платформ ORM, особенно если у вас есть время.
Однако без дополнительной информации трудно дать какие-либо рекомендации.
Мое практическое правило: если он доступен только для чтения, я готов сделать это в JDBC, хотя я предпочитаю использовать пустой проект Hibernate с SQLQuery, чтобы воспользоваться преимуществами сопоставления типов Hibernate.Когда мне нужно выполнить запись, я перехожу к Hibernate, потому что гораздо проще установить несколько атрибутов, а затем вызвать сохранение, чем устанавливать каждый столбец по отдельности.И когда вам нужно начать оптимизацию, чтобы избежать обновлений неизмененных объектов, вам будет гораздо лучше использовать OR/M и его грязную проверку.Работа с отношениями внешних ключей — еще один признак того, что вам нужно один раз сопоставить их, а затем использовать геттеры.Та же логика применима и к Toplink, хотя, если они не добавили что-то вроде HQL за три года с тех пор, как я его использовал, Hibernate будет намного лучше для такого перехода от чистого SQL.Имейте в виду, что вам не обязательно отображать каждый объект/таблицу, а только те, у которых есть явное преимущество.По моему опыту, большинство проектов, которые не используют существующий OR/M, в конечном итоге создают новый, что является плохой идеей.
А лучший способ изучить ORM — это небольшой проект.Начните этот проект.
Как только вы освоитесь, вы будете использовать ORM для всего.
Для ORM нет ничего слишком маленького.После первых нескольких проектов вы обнаружите, что не можете работать по-другому.Отображение ORM обычно имеет больше смысла, чем любой другой способ работы.
Посмотрите здесь различные руководства по топлинкам, в них есть введение, примеры, сценарии и т. д.
