Философия Hibernate

Эта статья — попытка облегчить поиски людям, начинающим в hibernate и столкнувшимся с тем же вопросом, что и я — а именно, как правильно писать на Spring Data (aka Hibernate). (Особенно это будет полезно программистам, пришедшим в java с слабо типизированных языков). Кода не будет, будут основные принципы, как же продуктивно использовать эту технологию.

Итак

Поскольку Hibernate — фреймворк для enterprise, сложно найти на нем примеры кода, которые были бы глубже обычного CRUD. Оный факт серьезно затрудняет понимание того, как же правильно писать на хибере, как себе представляли хороший код сами разработчики фреймворка — вследствие чего мне пришлось думать над этим вопросом самостоятельно. Уверен, что я не один.

@

Первое, что можно заметить — БД нет как абстракции. В hibernate сделано все, чтобы получить полный контроль над базой в коде (можно погуглить Entity Management). Ваша БД — это объекты домена, которые выполняют функцию почти тупого хранения. Отсюда важное правило: не надо их использовать не для чего, кроме хранения. Они не должны выполнять функции DTO, принимающего пользовательский ввод, не должны служить отображением при сериализации. У них — лапки.

@

Отсюда вытекает следующее правило — их совершенно не должен волновать формат использования. Нужен ли нам список продуктов (где будет только название и описание) или страница продукта (с фото и отзывами) — клиент получит в одном случае List из SimpleProductViewer (id, name, description), а в другом ExtendedProductViewer (id, name, description, List(photos), List(reviews), rating), которые будут сформированы в методах класса ProductService и использовать при этом классы домена только как источник данных.

То же самое и с вводом. Это Java, тут нормально сделать на каждый случай по DTO с разными полями)

Для примера я буду наращивать базу классов для избитого домена Product. Чего у нас уже есть:

1. Product (домен)
2. Viewer (классы для клиентского отображения информации, может быть сколько угодно)
3. Dto (классы для получения информации, тоже может быть сколько угодно)
4. Repository (для получения данных, причем полученные данные всегда должны представлять собой список объектов домена. Термин «глубина связей» тут неуместен, поскольку это не задача репо одного домена)
5. Service (или Manager) — черный ящик для неподконтрольной бизнес-логики, который объединяет все предыдущие пункты.

@

Мне кажется (кажется), что Java Enterprise не сильно парит оптимизация (это видно уже по запросам hibernate и самому факту, что ООП (hibernate) перетянуло на себя одеяло менеджмента сущностей БД). Поэтому главное в данном контексте — соответствие кода взглядам разработчиков фреймворка, что бы не было вопросов из раздела «WTF».

@

Если смотреть на домены hibernate таким взором (только хранение данных), @ManyToOne покажется механизмом, не так часто используемым и применимым только к полностью зависимым таблицам — изображения, отзывы, комментарии. В принципе, это нормально — на мой взгляд, не надо распространять их действие на стержневые таблицы вашей БД.

Резюмируя:

• Используйте домен только для хранения данных, желательно при этом чтобы данные находились в одной таблице.
• Не надо пытаться расширить домен — расширяйте классы отображения, а классы домена используйте только как поставщик данных.
• Не бойтесь плодить однотипные классы — понятность и гибкость использования важнее. Максимум, чего можно сделать для уменьшения объемов кода — наследовать их от домена.
• Не гонитесь за оптимизацией. Для джавовских пацанов не это важно, хотя, конечно, все зависит от контекста.

Все рекомендации выше это, конечно, мое ИМХО, которое, тем не менее, может оказаться полезным начинающим джавистам.

Всем бобра!)