Доклад представляет обзор использования ORM-технологий, таких как Hibernate и MyBatis, в разработке программного обеспечения. Он обсуждает примеры применения этих технологий, их преимущества и недостатки, а также рекомендации по интеграции в проекты с различными требованиями к производительности и архитектуре базы данных. Основное внимание уделяется созданию эффективных процессов разработки и документированию для успешной реализации отчетности и работы с данными.

1. Зиновьев Алексей,
Тамтэк
MyBatis & Hibernate,
давайте жить дружно

2. ● аспирант ОмГУ, математик;
● Java-девелопер в компании Thumbtack;
● занимаюсь теорией графов, прогнозированием
пробок, исследованием транспортных систем;
● большой фанат различных Maps API;
● лидер GDG Omsk.
О себе

3. О чем этот доклад
Тот же
Ibatis,
только в
профиль

4. Тут будем разминаться
● Кто хоть раз использовал ORM ?

5. Тут будем разминаться
● Кто хоть раз использовал ORM ?
● Кто хоть раз использовал Hibernate ?

6. Тут будем разминаться
● Кто хоть раз использовал ORM ?
● Кто хоть раз использовал Hibernate ?
● Кто хоть раз использовал MyBatis ?

7. Тут будем разминаться
● Кто хоть раз использовал ORM ?
● Кто хоть раз использовал Hibernate ?
● Кто хоть раз использовал MyBatis ?
● Кто хоть раз плевал на все и писал
свой QueryEnterpriseSQLBuilder ?

8. Жил-был один проект
● Как бы плагин к одной
известной базе
● JDBC - лапша в коде
● Одна база readonly
● Требуется аналитическая
отчетность
● Немного Hibernate для пары
таблиц в собственной базе
● Сборка отчетов в коде

9. Почему на проекте появился
Hibernate
● несколько удобных сущностей, для которых
были на первых порах нужны только CRUD -
операции;
● сущности были древовидными, хороши для HQL;
● легкая разметка аннотациями существующей
модели;
● Criteria API для недругов SQL;
● архитектору просто нравился Hibernate.

10. Волшебная палочка Hiber?
● Пасует в сложных
запросах
● Сложные связи между
таблицами превращаются
в неожиданные объекты
● Плох для больших
выборок данных
● Не прост в изучении
● Необъяснимые падения
производительности

11. Шло время, изменялись
требования ...
● Росло финансирование
● На проекте менялись
программисты
● Появились и были
сформулированы цели
● Росло число методов в
DAO - классе (sic!)
● Код переполнялся
низкоуровневыми
List<List<List<?>>>

12. Цели
● Производительность
программиста
● Легко расширяемый
функционал
● Быстрая работа с БД
● Кэширование
● Уход от сборки данных
отчета в коде
● Минимальная скорость
добавления одного отчета

13. MyBatis Mac'iBatis
● конфигурирование в коде или в специальном
файле;
● выгрузка результата запроса в объект;
● стандартный кэш или собственный;
● динамическая безопасная сборка SQL (целых
секций) в зависимости от параметров, позволяет
сократить число запросов;
● возможность использования аннотаций или map
- файлов (аннотации менее популярны).

22. Обобщим?

23. App case #1
● Новый проект
● Часто меняющаяся схема
БД
● Неясная иерархия
объектов
● Пока нечего
анализировать
● Много write, мало read
● No JOINs

24. Ну вы поняли, что это не наш
пациент ...

25. App case #2
● Есть давно рабочая БД
● Нет контроля над схемой
● Сбор аналитики,
построение отчетов
● Хранимые процедуры
● Много read
● Нужны JOINs
● Приложение для
работающего бизнеса

26. Для чего удобен Hibernate
● Нужно что-то кэшировать
● Хорош в работе с
деревьями объектов
● Множество CRUD -
операций
● Есть стабильные, ясные
сущности
● Контроль над схемой БД
● Создание прототипа

27. Для чего удобен JDBC
● Критичные по
производительности
места
● Сложные запросы,
получающие простые
ответы
● Для обучения новичков
● Мсье знает толк...

28. Для чего удобен MyBatis
● хранения и разработки
сложных SQL - запросов;
● для замены JDBC;
● для нетривиальных
сущностей, которые
собираются из нескольких
таблиц;
● для урезанных версий
сущностей;
● для динамических
семейств SQL.

29. Проблемы интеграции
● Люди испытывают разные
чувства к SQL
● Спорные ситуации,
передел сфер влияния
● Мало удачных примеров
для MyBatis в сети
● Теперь надо учить две
технологии вместо одной?

30. Процесс внедрения
● Общественный договор
● Документирование сфер
влияния
● Диаграммы dev-процессов
(как на проекте добавить
новый отчет)
● Чувство прекрасного

31. Добавление нового отчета
(пример dev-процесса)
● добавляем 1 запрос типа select;
● добавляем 1 Result map (не обязательно);
● добавляем 1 класс, соответствующий строке
отчета;
● добавляем 1 функцию в DAO, получающюю
список ResultMap объектов по псевдониму.
Эта функция возвращает множество строк отчета.
Изменение логики запроса приводит лишь к
изменению SQL - запроса.

32. Простые шаги
Следует начать с того, чтобы промаркировать таблицы
данных следующим образом:
● READONLY - контент, который поставляется нам со
стороны;
● REPORT - таблицы, поставляющие данные для
аналитической отчетности;
● ENTITY - удобные для понимания сущности,
которые нужно будет редактировать;
● PART OF ENTITY <ENTITY_NAME> - часть удобной
сущности ( в скобках указана сущность).

33. Простые шаги
Все таблицы с меткой ENTITY можно прогнать сквозь
мясорубку хибернейтовского Reverse Engineering, создав по
ним классы - сущности.
Для сущностей распавшихся по таблицам, с меткой PART OF
ENTITY <ENTITY_NAME> мы руками создаем классы по
стандарту JPA или пишем map - файл для Hibernate сами,
или определяем foreign keys (если это возможно в БД) и
полагаемся на Reverse Engineering.
Для READONLY и REPORT стоит написать запрос, который
на выходе получает список строк отчета, которые маппятся в
коллекцию (List) объектов типа "строка отчета"

34. Hibernate + MyBatis
● Могут жить на одном
проекте
● Строгое разграничение
сфер
● Большие отчеты - MyBatis
● Entity - в Hibernate
● Высокая скорость
разработки
● ORM на проекте - шаг к
MVC

35. Контакты и полезные ссылки
● Руководство по Hibernate
● Статья в моем блоге по теме доклада
● Сайт MyBatis
● Моя почта: zaleslaw.sin@gmail.com
● Мой профиль в Google+

36. Да пребудет с вами DAO!

37. Вопросы?
Зиновьев Алексей,
Тамтэк
zaleslaw.sin@gmail.com