- Подписка на печатную версию:
- Подписка на электронную версию:
- Подшивки старых номеров журнала (печатные версии)
LXF74-75:Что за штука...
Материал из Linuxformat.
Хотите сэкономить время на кодировании запросов к базе данных? Скотт Дуглас (Scott Douglass) подскажет, как это сделать.
- >> Hibernate… то есть спячка… это не то, чем зимой занимаются медведи?
Так и есть, но вместо долгих часов зимней спячки они в это время изобретают новый способ сохранения объектов Java в базе данных.
- >> Разве в базах данных хранятся объекты, а не данные?
Да, обычно вы храните свои данные в базе и получаете доступ к ним с помощью специального API. А используя объектно-ориентированный язык Java, вы бы считывали данные в Java-объект при помощи SQL-запросов. Объектом можно как угодно манипулировать, а потом записать данные обратно в базу, опять-таки при помощи SQL и JDBC API (JDBC — Java Database Connectivity). Однако если выключить компьютер, не сохранив данные из объекта, то они будут потеряны. Объекты Java могут существовать только в виртуальной машине Java — Sun не проектировал Java для записи на жесткий диск; поэтому объекты не переходят из сессии в сессию. Многие люди задумались: а что если сохранять Java-объект непосредственно в базе данных, без нудных SQL-запросов и кода JDBC? Вот тут и нужен Hibernate — он обеспечивает объектно-реляционное отображение (ORM — Object Relational Mapping) между объектом и БД.
- >> Отлично. А он написан медведями-гризли или бурыми медведями?
Пожалуй, надо прояснить ситуацию с медведями…
На самом деле проект разрабатывается замечательными ребятами из JBoss, и лицензирован по LGPL.
- >> Постоянное хранение объектов, хм-м, а разве не для этого предназначалась технология Enterprise Java Beans?
Enterprise Java Beans (EJBs) — это серверные объекты, которые живут в контейнере в сервере приложений. Hibernate предоставляет ряд преимуществ по сравнению с EJBs, точнее, с их разновидностью, называемой entity beans. Интересной особенностью этих «бобов» является наличие у них сохраняемого состояния. Существует два способа его сохранения: сохранение, управляемое контейнером (CMP — container managed persistence), при котором состоянием бина распоряжается контейнер J2EE (Java 2, Enterprise Edition), и сохранение, управляемое бином (BMP — Bean Managed Persistence), при котором бин сам контролирует свое состояние. В отличие от CMP, Hibernate позволяет отображать несколько таблиц на один Java-объект или описывать несколько Java-объектов одной таблицей. Аналогичный результат можно получить и через BMP, но тогда потребуется самим написать всю JDBC-логику внутри бина.
- >> То есть Java-объекты должны быть записаны особым образом? А не могу я просто сохранить любой объект?
В Hibernate — можете. Он позволяет сохранять практически любой Java-класс, разработанный с помощью стандартных объектно-ориентированных методов, благодаря чему "срабатывают все сильные стороны Java: наследование (когда один класс выводится из другого), композиция (включение новых членов) и даже группировка классов в «коллекции». По сути, вы можете разрабатывать Java-приложения, почти не заботясь о том, каким образом Hibernate сохранит ваши объекты.
- >> И мне не придется писать большой объём тупого JDBC кода?
Нет — как только вы создадите свой Java-объект и определите его отображение, код, который вам нужно будет написать для сохранения или восстановления объекта, будет минимальным, по сравнению с JDBC-вызовами и связанной с ними обработкой ошибок.
- >> Что такое отображение?
Хороший вопрос. Hibernate должен знать, какие таблицы относятся к каким объектам, и для этого он использует карту в формате XML. Вы, конечно, можете создать один большой XML-файл, содержащий отображение всех ваших объектов, но Hibernate позволяет завести отдельный файл для каждого объекта. В этом случае у вас будет набор небольших файлов, имеющих чёткое назначение.
- >> Переписать все мои таблицы в формате XML — мороки не меньше, чем наготовить те же JDBC-вызовы…
Если у вас всего лишь один-два объекта, которые вы хотите использовать с Hibernate, то написать XML — невеликий труд: формат весьма прост. Для случая, когда у вас множество объектов, Hibernate позаботился о механизмах автоматической генерации соответствующих файлов.
- >> Ого! Он может сам создавать свои конфигурационные файлы?
Может, но вам придётся следовать некоторым правилам при проектировании своих объектов. Ничего особо революционного: просто надо предусмотреть конструктор по умолчанию и методы доступа к полям (get/set). На самом деле Hibernate поставляется с утилитой генерации схемы базы данных или шаблона из вашего файла с отображением. Это означает (в теории), что если вы создали Javaобъект, который хотите сохранить с помощью Hibernate, вы можете воспользоваться утилитами для генерации файла отображения и последующей генерации из него схемы базы данных.
- >> Но мне по прежнему нужен какой-нибудь контейнер, так?
На самом деле нет. В отличие от EJB, которым требуется сервер приложений J2EE (например, JBoss), Hibernate не требует никакого специального окружения. Это делает его гораздо более легковесным, чем EJBs, и пригодным для автономных приложений.
- >> Не приводит ли к потере производительности то, что Hibernate не использует контейнер?
Видимо, нет. Печально известно, что EJB работают медленно, несмотря на то, что живут внутри своего контейнера. Hibernate, хотя и запускается немного подольше, считается очень быстрым. Разработчики Hibernate утверждают, что он может быть даже быстрее решения с использованием SQL/JDBC, поскольку сгенерированные Hibernate запросы могут содержать кэширование данных и другие оптимизации.
- >> А если я хочу сделать со своими данными что-нибудь похитрее, но у меня нет первичного ключа для объекта, который надо вытащить?
Под первичным ключом вы, конечно, понимаете индивидуальный идентификатор, заданный для каждой записи таблицы. Что ж, как это ни удивительно, но вместо написания SQL запросов и выполнения их с помощью JDBC вы можете воспользоваться собственным объектным языком Hibernate — HQL (Hibernate Query Language). На этом языке можно напрямую делать запросы к объектам и их свойствам. Запросы выходят более компактными, чем их эквивалент в SQL, поскольку HQL учитывает отношения, заданные в отображении, и их не надо указывать в самом запросе. Hibernate также допускает использование канонического SQL, но разработчики не рекомендуют этого делать.
- >> Выглядит неплохо, но разве не то же
самое обещано в новом стандарте EJB3? Зачем нам Hibernate, когда Sun скоро будет иметь кое-что получше? Текущий стандарт EJB не позволяет организовывать объектно-реляционное соответствие, но следующее воплощение стандарта (EJB3) будет включать и стандарт на ORM. Определённо парни из Sun знают, что делают, поэтому они и позволили разработчикам Hibernate участвовать в создании стандарта. Hibernate оказал заметное влияние на дизайн EJB3.
На самом деле, поскольку Hibernate предполагает тот же набор требований к коду, что и entity beans, использующие прозрачное сохранение объектов, вы сможете использовать Hibernate как управляющий компонент EJB-контейнера — другими словами, как первичный интерфейс для взаимодействия с бинами во время выполнения. Другой момент в пользу Hibernate — то, что он есть уже сейчас, тогда как EJB3 ещё предстоит пройти через процесс спецификации JSR (JSR — Java Specification Request). Hibernate — образец зрелой технологии, он хорошо протестирован и в большей или меньшей степени представляет собой промышленный стандарт.
- >> Пожалуй, мне это нравится. Как я могу его опробовать?
Вы можете взять его с прилагаемого диска или скачать последнюю версию с http://www.Hibernate.org. Останется только распаковать архив и собрать его с помощью Apache Ant (http://ant.apache.org — незаменимый инструмент сборки для Java-разработчика). На Web-сайте вы найдёте более подробные инструкции.
- >> Что мне делать, если сама идея отображения мне подходит, а Hibernate — нет? Есть ли альтернативы?
Существует множество различных инструментов объектно-реляционного отображения. Какой вы выберете, будет зависеть от вашей ситуации. Сравнение некоторых из них приведено здесь: http://c2.com/cgi/wiki?ObjectRelationalToolComparison. Другой популярный ORM-продукт — Object Relational Bridge (OJB) из проекта Apache (http://db.apache.org/ojb). Он несколько новее Hibernate, но поскольку это продукт Apache, проблем со стабильностью и поддержкой быть не должно. Он поддерживает несколько API сохранения объектов, так что вы можете выбрать наиболее подходящий. Cтоит также взглянуть на инструмент реляционного отображения TopLink от Oracle (http://www.oracle.com/technology/products/ias/toplink/index.html). Он доступен в составе Oracle Application Server или отдельно (не бесплатно), и совместим с Oracle или другими базами данных.