Библиотека сайта rus-linux.net
OSCAR
Глава 16 из книги "Архитектура приложений с открытым исходным кодом", том 2.
Оригинал: OSCAR
Автор: Jennifer Ruttan
Перевод: А.Панин
16.4. Модели данных/DAO
При изучении дерева исходного кода проекта OSCAR вы можете заметить, что существует множество различных способов осуществления доступа к базе данных: вы можете использовать прямое соединение с базой данных с помощью класса с именем DBHandler, устаревшее соединение с использованием модели Hibernate или модель JPA общего назначения. По мере появления новых и более простых моделей взаимодействия с базой данных, они интегрируются в состав проекта OSCAR. В результате на данный момент процесс взаимодействия системы OSCAR с данными из базы данных MySQL является не достаточно очевидным и различия между тремя описанными методами доступа к данным могут быть описаны лучшим образом с помощью примеров.
Система EForm позволяет пользователям создавать свои формы для привязки их к записям пациентов - эта возможность обычно используется для замены бумажных бланков на их цифровые версии. При каждом создании формы определенного типа загружается шаблон формы из файла; после этого данные формы сохраняются в базе данных для каждого ее экземпляра. Каждый экземпляр формы привязывается к записи пациента.
Система EForms позволяет вам запрашивать определенные типы данных из списка пациентов или другой области данных системы с использованием SQL-запрсов в свободной форме (которые заданы в файле с именем apconfig.xml). Это может быть очень полезным, так как форма может быть загружена, после чего немедленно заполнена демографическими данными или другой соответствующей информацией без вмешательства пользователя; например, вам не придется вписывать имя пациента, его возраст, дату рождения, место рождения, номер телефона или последнюю медицинскую запись при работе с конкретным пациентом.
При начальном проектировании модуля EForm было принято архитектурное решение, заключающееся в использовании необрабатываемых запросов к базе данных для заполнения POJO (простого Java-объекта в старом стиле - plain-old Java object) с именем EForm в контроллере, который впоследствии передается на уровень представления для вывода данных на экран так, как это сделано с JavaBean. Использование объекта POJO в данном случае приближает архитектурное решение к решениям Hibernate или JPA, о которых я расскажу в следующих разделах.
Все функции, относящиеся к сохранению экземпляров класса EForm и шаблонов, осуществляются с помощью необрабатываемых SQL-запросов, выполняемых классом DBHandler. В конечном счете, класс DBHandler является оберткой над простым объектом JDBC и не проводит исследование запроса перед его оправкой серверу SQL. Следует добавить, что использование класса DBHandler является потенциальной угрозой безопасности, так как он позволяет отправлять серверу непроверенные SQL-запросы. Любой класс, использующий класс DBHandler, должен реализовывать свои собственные алгоритмы проверки для того, чтобы быть уверенным в неосуществимости SQL-инъекции.
В зависимости от типа приложения, которое вы разрабатываете, прямой доступ к базе данных иногда может оказаться подходящим решением. В определенных случаях такая возможность позволяет даже повысить скорость разработки. Использование этого метода для доступа к базе данных не соответствует шаблону проектирования "модель-представление-контроллер", хотя в том случае, если хотите изменить структуру вашей базы данных (модель), вам придется изменить SQL-запрос в другом месте (в контроллере). Иногда добавление определенных столбцов или изменение их типов в таблицах базы данных системы OSCAR требует выполнения подобной процедуры вмешательства всего лишь для реализации простейших возможностей.
Вас может не удивлять тот факт, что объект DBHandler описан в одной из старейших частей исходного кода и все еще является нетронутым. Лично я не знаю, где он возник, но я предполагаю, что этот класс является наиболее "примитивным" типом класса для доступа к базе данных в рамках дерева исходного кода системы OSCAR. Новый исходный код не может использовать этот класс, а в том случае, если использующий его исходный код все же попытаются добавить в репозиторий, он будет автоматически отклонен.
Демографическая запись содержит основные метаданные, имеющие отношение к пациенту: например, его имя, возраст, адрес, родной язык и пол; будем считать, что эти данные появляются после заполнения пациентом формы приема в ходе его первого визита к врачу. Все эти данные извлекаются и выводятся в форме части мастер-записи системы OSCAR (OSCAR's Master Record) для определенной демографической записи.
Использование Hibernate для осуществления доступа к базе данных значительно безопаснее использования класса DBHandler. С одной стороны вам приходится четко указывать то, какие столбцы соответствуют каким полям вашего объекта модели (в данном случае, класса Demographic). Если вы хотите выполнить сложные объединения запросов, они могут быть осуществлены с использованием заранее подготовленных объявлений. Наконец, вы получите объект исключительно того типа, который вы описывали при осуществлении запроса, что очень удобно.
Процесс работы с парами объектов доступа к данным (DAO) и моделей при использовании Hibernate достаточно прост. В случае объекта Demographic существует файл с именем Demographic.hbm.xml, который описывает связи между полями объекта и столбцами таблицы базы данных. Файл описывает то, к какой таблице следует обратиться, а также какой тип объекта следует вернуть. При запуске системы OSCAR данный файл должен быть прочитан, после чего должна быть проведена проверка достоверности прочитанных данных, предназначенная для того, чтобы быть уверенным в реальной возможности создания описанного типа связей (в случае неудачной проверки процесс запуска севера прерывается). В процессе работы сервера вы можете создать экземпляр класса DemographicDao и выполнять запросы с помощью него.
Преимуществом использования Hibernate по сравнению с DBHandler является то, что все запросы к серверу базы данных осуществляются с использованием заранее подготовленных объявлений. Это обстоятельство ограничивает возможность свободного выполнения SQL-запросов в процессе работы системы, но при этом также предотвращает любые типы атак на основе SQL-инъекций. Hibernate всегда будет формировать сложные запросы для выборки данных, причем запросы не всегда формируются чрезвычайно эффективным способом.
В предыдущем разделе я упомянула о примере модуля EForm, использующего класс DBHandler для заполнения объекта POJO. Это еще один логический шаг, направленный на предотвращение разработки подобного кода. В случае изменения модели придется изменить только файл с расширением .hbm.xml и класс модели (добавить новое поле и новые функции для получения/установки значений в новом столбце), причем эти действия не затронут остальных частей приложения.
Хотя метод работы с Hibernate и современнее метода обращения к базе данных посредством класса DBHandler, он начинает устаревать. Его не всегда удобно использовать, а также он требует файла конфигурации большого размера для каждой таблицы базы данных, доступ к которой вы хотите получить. Добавление новой пары объектов занимает время и в том случае, если вы выполните эту операцию некорректно, система OSCAR даже не начнет работу. По этой причине в любом случае никто не должен разрабатывать новый код, использующий Hibernate напрямую. Для замены описанной технологии на новом этапе разработки была предложена технология JPA.
Далее: Интегратор согласования (JPA)