Чем хорош iBatis
Java разработчики имеют довольно богатый выбор инструментов, упрощающих взаимодействие системы с реляционной СУБД. Среди них особой популярностью пользуются ORM-средства, которые позволяют отобразить объектную модель предметной области на модель реляционную, а затем работать с объектной моделью, не особо заботясь о ее реляционном представлении. Тем не менее, есть и другие инструменты, представляющие собой другой подход к связыванию объектной и реляционной модели данных. Одним из таких инструментов является iBatis. И сейчас я хочу поделиться причинами, по которым я выбираю этот инструмент.
Простота и легкость освоения
iBatis действительно очень прост в освоении. Для того, чтобы начать использовать его в своих проектах вовсе не нужно обладать специальными знаниями. Достаточно знать SQL и потратить немного времени на понимание того, как описывать сами запросы, как отображать результаты запросов на объекты и обратно. Все остальные аспекты работы с СУБД через iBatis так же просты. Разработчики довольно хорошо позаботились о том, чтобы сделать этот инструмент простым и понятным.
SQL отдельно, код отдельно
Все SQL-запросы iBatis хранит в специальных файлах в виде XML. Это во-первых, делает программный код проекта чистым и понятным, что позволяет сосредоточиться на логике решаемой задачи, а не на логике работы с базой данных.
А во-вторых, позволяет в любой момент времени получить представление о наборе SQL-запросов, используемых применительно к системе в целом или относительно конкретной сущности в частности1.
Отображение результатов запроса на объектную модель
Так же как и ORM-инструменты iBatis позволяет отобразить данные из базы данных на объект, представляющий собой сущность предметной области. Тогда как ORM подразумевает некое отношение между объектной моделью предметной области и ее представлением в реляционной модели, iBatis дает возможность преобразовать результат SQL-запроса на объектную модель приложения. В результате разработчик получает дополнительную гибкость при работе к примеру с унаследованной базой данных, структура которой плохо ложится на объектную модель. Способ отображения задается на уровне описания SQL-запроса и может использоваться повторно для нескольких запросов.
Гибкая параметризация запросов
Редко когда запрос к базе данных не содержит параметров. При работе с базой данных через JDBC, значения параметров запроса задаются либо через порядковые номера параметров, либо через их имена. И если именованные параметры довольно легко использовать, то передача значений через номер параметра может превратиться в кошмар, особенно если запрос приходится переписывать, что неизбежно ведет к перенумерации параметров.
В iBatis параметр может быть объектом (например String или ArrayList), набором вида ключ/значение (например HashMap) или бином, поля которого содержат необходимые значения. Синтаксис описания запросов позволяет обращаться к значениям объектов и к значениям их полей по имени, что делает параметры самодокументирующимися, а запрос понятным.
Динамические SQL-запросы
Как же часто требования к системе требуют генерации SQL-запросов по ходу выполнения программного кода в зависимости от различного рода условий, таких как состояние объекта или данные пользовательского ввода. В результате код выглядит громоздким и запутанным, подвержен ошибкам и требует немало времени и нервов для его отладки. Как легко допустить оплошность и заставить код генерировать неверный запрос из-за небольшого изменения в логике, выраженной многочисленными условными операторами. И как достало морщиться от вездесущей конструкции "1=1" в выражении where, позволяющей не думать о том, начинать ли следующее условие с оператора AND или нет.
Действительно, императивные языки не очень подходят для решения подобных задач, и использование декларативного стиля напрашивается само собой. iBatis предоставляет средства для динамической генерации SQL-запросов именно в такой манере. Условия для включения SQL-выражений, условия контроля вставки предшествующих выражений и операторов, конструкции для итерирования по массивам и коллекциям, все это для того, чтобы облегчить жизнь разработчика. И все это отдельно от программного кода.
Повторное использование SQL выражений
Чем более сложным является разрабатываемое приложение, чем больше в нем функциональности, требующей обращения к базе данных, тем чаще эта функциональность пересекается. Довольно распространенной является ситуация, когда казалось бы разные SQL-запросы должны следовать неким общим правилам, что нередко приводит к частичному дублированию одних и тех же выражений. Хорошей практикой в программировании является следование принципу DRY2. Разработчики iBatis нашли место применению этого принципа и в написании SQL-запросов.
Поддержка кэширования
Кэширование данных — отличный способ повышения производительности приложения. В самом деле, зачем каждый раз запрашивать данные из базы, если их можно хранить например в памяти. Конечно не всякие данные будут хорошими кандидатами для кэширования, но речь сейчас не об этом. Речь о том, что iBatis поддерживает различные модели кэширования, а так же дает средства по управлению ими. Кроме собственных моделей кэширования, так же поддерживается решение OSCaсhe. Самая приятная особенность состоит в том, что определение модели кэширования и управление кэшем производится декларативно, без единой строчки кода.
Расширяемость
В большинстве случаев разработчикам достаточно тех возможностей, которые дает iBatis. Но в тот момент, когда потребуется записать в базу данных объект, который плохо ложится на реляционную модель и его нужно сериализовать в виде двоичных данных, или проектной команде приходится использовать решение для кэширования данных, навязанное заказчиком... в тот момент, когда кажется, что все пропало, и выбранный инструмент не совместим с предъявляемыми требованиями... именно в этот момент, можно вздохнуть с облегчением, потому как iBatis является расширяемой библиотекой, и следует концепции pluggable component design. Написание собственного обработчика типов, или собственного контроллера для кэша, не составит особого труда.
Интеграция со Spring Framework
Spring Framework завоевал большую популярность среди Java-разработчиков. Не буду останавливаться на особенностях самого фреймворка, скажу лишь то, что iBatis хорошо с ним интегрирован, и дает возможность использования всех прелестей Spring, включая конфигурирование посредством IoC 3 и декларативное управление транзакциями.
1 Это иногда требуется. При этом к примеру аналитики, довольно хорошо знают SQL, и нисколько не интересуются премудростями автоматической генерации запросов ORM средствами.
2 DRY (Don't Repeat Yourself) — не повторяй себя. Принцип программирования, при котором разработчики стремятся избегать дублирования кода и использовать его повторно. (См. так же: Повторное использование кода)
3 IoC (Inversion of Control) — инверсия управления. Дизайн-принцип объектно-ориентированного программирования, по которому все зависимости компонента определяются отдельно от стадии конструирования этого компонента и передаются ему извне. Следование этому принципу позволяет уменьшить связность системы. (См. так же: IoC)
Оставить комментарий