Когда использовать Hibernate/JPA/Toplink?
Прямо сейчас я делаю очень простой сайт - около 5 страниц. Вопрос в том, является ли излишним и стоит ли время интегрировать какое-либо решение для отображения базы данных или было бы лучше использовать просто старый JNDI. У меня будет, возможно, дюжина вещей, которые мне нужно будет прочитать / написать из базы данных. Я предполагаю, что у меня есть базовое понимание этих технологий, но все равно потребуется много ссылок на документацию. Кто-нибудь еще сталкивался с решением раньше?
РЕДАКТИРОВАТЬ: Извините, я должен был указать JNDI для поиска соединения с БД и JDBC для выполнения операций.
6 ответов
Краткий ответ: это зависит от сложности, которую вы хотите поддерживать.
Длинный ответ:
Во-первых, ORM (реляционное сопоставление объектов - отображение базы данных, как вы его называете) и JNDI (интерфейсы именования и каталогов Java) - это две разные вещи.
Первый, как вы уже знаете, используется для сопоставления таблиц базы данных с классами и объектами. Второе - предоставить механизм поиска ресурсов, это могут быть DataSources, Ejb, Queues или другие.
Может быть, вы имеете в виду "JDBC".
Теперь о вашем вопросе: если это так просто, возможно, нет необходимости внедрять ORM. Числовые таблицы должны быть не более 5 - 10, а операции, я думаю, очень просты.
Вероятно, будет достаточно использовать простой JDBC.
Если вы используете шаблон DAO, вы можете изменить его позже, чтобы поддержать стратегию ORM, если это необходимо.
Вот так: скажем, у вас есть таблица сотрудников
Вы вручную создаете Employee.java со всеми полями БД (это не должно занять много времени) и EmployeeDaO.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 Application Server".
Я оставляю вам некоторые ресурсы, где вы можете получить больше информации об этом:
В этой книге "Шаблоны архитектуры корпоративных приложений" Мартин Фаулер объясняет, где использовать то или иное, вот каталог. Взгляните на архитектурные шаблоны источников данных и объектно-реляционные поведенческие шаблоны:
DAO (объект доступа к данным) является частью основного каталога шаблонов J2EE:
Это начальное руководство для Hibernate:
Официальная страница Toplink:
Наконец, я "думаю", что хорошей идеей JPA является то, что вы можете поменять провайдеров в последнее время.
Начните с простого, а затем развивайтесь.
Надеюсь, это поможет.
Похоже, что для очень простого приложения это было бы излишним, особенно если у вас нет планов его расширять. Тем не менее, также может показаться целесообразным использовать их в этом простом приложении, чтобы вы лучше понимали, как они работают, в следующий раз, когда у вас будет что-то, что может их использовать.
Лучший способ изучить ORM - это небольшой проект. Начните с этого проекта.
Как только вы это освоите, вы будете использовать ORM для всего.
Для ORM нет ничего слишком маленького. После первых двух проектов вы обнаружите, что не можете работать по-другому. Отображение ORM, как правило, имеет больше смысла, чем почти любой другой способ работы.
Вы имеете в виду старый добрый JDBC? Небольшой проект может быть хорошей возможностью выбрать одну из платформ ORM, особенно если у вас есть время.
Однако, без дополнительной информации трудно так или иначе дать рекомендацию.
Мое эмпирическое правило, если оно доступно только для чтения, я хочу сделать это в JDBC, хотя я предпочитаю использовать пустой проект Hibernate с SQLQuery, чтобы воспользоваться преимуществами отображения типов Hibernate. После того, как мне нужно сделать записи, я использую Hibernate, потому что намного проще установить несколько атрибутов и затем вызвать save, чем устанавливать каждый столбец отдельно. А когда вам нужно начать оптимизацию, чтобы избежать обновлений на неизмененных объектах, вам гораздо лучше с OR/M и его грязной проверкой. Работа с отношениями по внешнему ключу является еще одним признаком того, что вам нужно отобразить его один раз, а затем использовать геттеры. Та же логика применима к Toplink, хотя, если бы они не добавили что-то вроде HQL за 3 года, прошедшие с момента его использования, Hibernate был бы намного лучше для такого перехода от чистого SQL. Имейте в виду, что вам не нужно отображать каждый объект / таблицу, только те, в которых есть явное преимущество. По моему опыту, большинство проектов, в которых не используется существующий OR/M, в конечном итоге создают новый, что является плохой идеей.
Посмотрите на различные руководства toplink здесь, у них есть введение, примеры, сценарии и т. Д.