Частина перша

Оскільки без підтримки баз даних не обходиться практично жодне сучасне додаток, то питань взаємодії з ними приділяється пильна увага у всіх підручниках з програмування. На жаль, про таку корисну річ, як ORM, в підручниках чомусь пишуть нечасто.

Що таке ORM?

Можливо, дехто з читачів вже стикався з цим терміном, однак, вважаю, таких буде небагато, оскільки навряд чи прагматичний інженерний розум програміста підкаже йому читати статтю по темі, яка йому і так вже добре знайома з практики. Хоча таке читання, безперечно, і буде дуже корисним, проте є тисяча важливіших справ. Втім, мова зараз не про них, так само як і не про користь читання. Про що ж тоді? Природно, про ORM.

У кожної милозвучно абревіатури існує безліч розшифровок. Ми будемо говорити про ту з них, яка звучить як object-relational mapping, або, якщо записати те ж саме, але тільки вже по-російськи, - об'єктно-реляційна проекція. Термін, що й казати, для непосвяченого звучить ой як хитромудро, однак, насправді, нічого концептуально складного в ньому немає.

Велика частина мов програмування, які використовуються сьогодні в індустрії програмування, відносяться до об'єктно-орієнтованим мовам. Це означає, що програміст, створюючи програми на них, оперує з об'єктами - деякими абстрактними сутностями, що мають деякі властивості і дозволяють застосовувати по відношенню до себе деякі методи. При всьому при цьому бази даних, які використовуються для зберігання інформації про ці об'єкти, є реляційними.

За прикладами далеко ходити не треба - візьмемо будь-тематичний інтернет-магазин, написаний, скажімо, на тому ж PHP. Всі товари, що містяться в списку, зручно зробити об'єктами і приписати їм певні поля, які залежать від виду товару. Для мобільного телефону це можуть бути розмір екрану і ємність батареї, для автомобіля - пробіг і рік випуску, а для лазерної мишки - час відгуку сигналу. При зчитуванні інформації про товар з такої бази програмісту доводиться писати багато допоміжного коду, який займається зчитуванням певних полів з бази, і присвоєнням лічених значень полів відповідних об'єктів. Добре, якщо ви можете зробити це один раз - прочитавши все, заспокоїтися і користуватися отриманою інформацією всі наступні рази. А якщо немає, і зчитувати потрібно неодноразово, та ще й, не дай Бог, записувати? Ось вже тоді обсяг рутинного коду зростає досить відчутно.

В общем-то, виходів з цієї ситуації може бути кілька. Скажімо, можна використовувати замість реляційної СУБД об'єктно-орієнтовану - тобто, таку, в якій інформація зберігається не у вигляді звичних всім таблиць, а у вигляді точно таких же об'єктів, якими оперують програмісти в своєму коді. Що ж, ідея хороша, тим більше, що існують системи управління базами даних, що дозволяють вирішувати цю проблему саме таким способом. Однак саме по собі використання об'єктно-орієнтованої СУБД призводить до цілого ряду нових проблем. Реляційні СУБД застосовуються так широко зовсім не тому, що вони незручні для програмістів - вони надійні, швидкі і, найголовніше, звичні.

Може, є який-небудь ще спосіб вирішення означеної проблеми? Звичайно є. Він, власне кажучи, і називається ORM. Полягає він в застосуванні спеціальних фреймворків або бібліотек, які самі займаються зв'язуванням об'єктів в програмі і записів в таблицях бази даних. Завдяки їм програміст частково позбавляється від набридливої ​​рутини і отримує більше часу для того, щоб думати над найважливішими аспектами реалізації проекту.

ORM-рішення мають багато переваг, в порівнянні з "ручний" роботою з базами даних в проекті. Вони дозволяють оптимізувати кількість запитів до бази даних, але при цьому уникнути завантаження надлишкових на даний момент для додатка даних. Крім того, завдяки єдиному для всіх використовуваних СУБД API-інтерфейсу, який надає ORM-фреймворк, в разі необхідності зміни СУБД за бажанням замовника або просто через надмірне зростання кількості даних дуже легко можна перейти з однієї СУБД на іншу, оскільки все SQL- діалекти вже реалізовані в фреймворку його розробниками, і програмісту, що використовує такий фреймворк, немає необхідності довгими зимовими вечорами вивчати кожен з них, щоб швидко і успішно перевести додаток в разі гострої необхідності з однієї СУБД н іншу. Хоча, звичайно, єдине API зручно не тільки в таких екстремальних випадках. Про це буде ще трохи сказано далі.

ORM і Java

Java - це така мова програмування, на якому в наші дні пишуть все. Ну, або майже все - починаючи від тих самих горезвісних інтернет-магазинів і закінчуючи складними розподіленими системами корпоративного рівня. Драйверів на ньому, звичайно, не пишуть, але він на це, правда, і не претендує.

Сучасні інтернет-додатки вельми і вельми активно використовують бази даних - само собою, реляційні, і найчастіше MySQL. Тому використання ORM-фреймворка в таких додатках - не розкіш, а засіб спокійного існування розробників. На щастя, звичайно ж, такий фреймворк для Java існує. Називається він, як можна побачити з назви цієї статті, Hibernate , А знайти його офіційний сайт можна за адресою hibernate.org. Поширюється Hibernate на умовах GNU Lesser General Public License, тобто, кажучи по-російськи, цей фреймворк просто вільніше вільного - його можна застосовувати в будь-яких додатках (в тому числі і в комерційних), працювати з його вихідними текстами, і т.д. і т.п.

Варто зауважити, що, хоча Hibernate - далеко не єдиний ORM-фреймворк для Java, він користується значною популярністю серед програмістів, оскільки це потужний, добре налагоджений і перевірений на безлічі реальних проектів програмний продукт.

Архітектура простого додатка, що використовує Hibernate, теж, вибачте за тавтологію, досить проста - ви можете побачити її на ілюстрації до статті. Як і очікувалося, Hibernate є сполучною ланкою між самим додатком і даними, що зберігаються в базі. При цьому зверніть увагу на два невеликих темніших прямокутника на фоні прямокутника з написом "Hibernate" - вони символізують конфігураційні файли, яким ми з вами повинні будемо приділити саме що ні на є пильна увага.

Робота з Hibernate

Як працює Hibernate? Завантаживши свою власну конфігурацію з файлу hibernate.cfg.xml, він збирає інформацію про класи, які розробник вирішив "замапіть" в базу даних зі спеціальних конфігураційних файлів, які записуються в форматі XML. Після завантаження всіх конфігураційних файлів можна створювати сесії підключення до бази даних за допомогою "фабрики сесій", і працювати з ними - змінювати дані, додавати, видаляти. Загалом, як то кажуть, повернути з даними все, що тільки душі буде завгодно.

Для початку давайте поговоримо про конфігуруванні Hibernate. Подивіться на лістинг - там ви можете побачити приклад конфігураційного файлу hibernate.cfg.xml для Hibernate; коментарі в ньому залишені для зручності читання. Ми з вами детально розберемо все, що в ньому написано.

&lt;? Xml version = '1.0' encoding = 'utf-8'?> <! DOCTYPE hibernate-configuration PUBLIC "- // Hibernate / Hibernate Configuration DTD 3.0 // EN" "http://hibernate.sourceforge.net/hibernate -configuration-3.0.dtd "> <hibernate-configuration> <session-factory> <! - Database connection settings -> <property name =" connection.driver_class "> org.hsqldb.jdbcDriver </ property> <property name =" connection.url "> jdbc: hsqldb: hsql: // localhost </ property> <property name =" connection.username "> sa </ property> <property name =" connection.password "> </ property> <! - SQL dialect -> <property name = "dialect"> org.hibernate.dialect.HSQLDialect </ property> <! - Echo all executed SQL to stdout -> <property name = "show_sql"> true </ property> <mapping resource = "events / Event.hbm.xml" /> <mapping resource = "events / Person.hbm.xml" /> </ session-factory> </ hibernate-configuration>

Перші два рядки, як водиться, пропускаємо - вони стандартні для всіх XML-файлів і не є специфічними для конфігураційних файлів Hibernate. hibernate-configuration - це елемент, який є кореневим для всього документа; session-factory описує параметри даної конкретної "фабрики сесій", з якої, в кінцевому підсумку, і буде працювати наш додаток. Властивості, озаглавлені в коментарі як "Database connection settings", дійсно вказують настройки підключення до БД: connection.driver_class - це клас JDBC-драйвера, що забезпечує підключення до потрібної СУБД (цей драйвер теж, як ви розумієте, повинен бути включений в проект); connection.url - це адреса для підключення до бази, який передається драйверу; connection.username і connection.password - це, відповідно, логін і пароль того користувача, від імені якого ми здійснюємо підключення до бази даних. Властивість dialect визначає клас SQL-діалекту, який Hibernate буде використовувати для підключення до бази даних. Використання властивості show_sql зручно при налагодженні - якщо його включити (виставити в true), то Hibernate буде виводити інформацію про всі посилаються до бази даних запитах на консоль. Поза налагодження це властивість краще робити false, оскільки в реальних додатках користувачеві не те що не потрібно бачити запити, а навіть і шкідливо з точки зору безпеки програми. Замикають наш конфігураційний файл два елементи, які починаються з "mapping resource ...". Це - шляхи до конфігураційним XML-файлів, в яких описані способи подання тих чи інших класів Java-додатка в реляційної базі даних, з якою це додаток через Hibernate буде працювати. Ці конфігураційні файли можуть бути досить складні через ієрархічних відносин між описаними в них класами, а тому про них ми з вами детально поговоримо вже в другій частині цієї статті.

Трохи про підтримуваних СУБД

Зараз я хотів би ще трохи зупинитися на списку систем управління базами даних, які підтримує фреймворк Hibernate. Офіційна підтримка гарантована для наступних СУБД: Oracle 8i, 9i, 10g; DB2 7.1, 7.2, 8.1, 9.1; Microsoft SQL Server 2000; Sybase 12.5 (JConnect 5.5); MySQL 3.23, 4.0, 4.1, 5.0; PostgreSQL 7.1.2, 7.2, 7.3, 7.4, 8.0, 8.1; TimesTen 5.1, 6.0; HypersonicSQL 1.61, 1.7.0, 1.7.2, 1.7.3, 1.8; SAP DB 7.3; InterSystems Cache '2007.1. Неофіційно Hibernate протестований (притому успішно) також на сумісність з наступними СУБД: Apache Derby, HP NonStop SQL / MX 2.0, Firebird 1.5, FrontBase, Informix, Ingres, Interbase 6, Mckoi SQL, Pointbase Embedded 4.3, Progress 9, Microsoft Access 95, 97, 2000, XP, 2002, 2003; Corel Paradox 3.0, 3.5, 4.x, 5.x, 7.x, 11.x; dbase, Visual DBASE, SIx Driver, SoftC, Codebase, Clipper, Foxbase, Foxpro , VFP, xHarbour, Halcyon, Apollo, Goldmine, BDE. Також в якості джерел даних можна вказувати прості текстові файли, CSV і TSV, а також файли Microsoft Excel.

Як бачите, список підтримуваних СУБД вийшов досить-таки значним, що зайвий раз підтверджує популярність і успішність фреймворка, про який ми з вами зараз ведемо розмову. На жаль, на цей раз поки що все - газетні статті, як відомо, мають деякі обмеження за обсягом, а тому розмова про Hibernate продовжимо в наступного номері.

Вадим СТАНКЕВИЧ