При использовании Hibernate ORM я должен сначала смоделировать диаграмму классов или диаграмму БД?

Question

Я довольно новичок в Java и Hibernate. На работе мы разрабатываем средние по размеру, обрабатывающие веб-приложение J2EE с использованием Spring, Hibernate, JBOSS и так далее. Как правильно использовать Hibernate? Должен ли я сначала создать диаграмму классов и сопоставить ее, используя hibernate с таблицами БД, или я должен сначала смоделировать таблицы БД, а затем сопоставить ее с объектами Hibernate? Или это зависит? Если это зависит от чего? Имеет ли один из этих подходов недостатки по сравнению с другим? Можно ли сопоставить «любую» диаграмму классов с БД с помощью Hibernate 4?

Answer 1

Оба подхода верны, но используются в разных ситуациях.

1. При создании нового приложения (новой модели) обычно сначала создаются сущности, а в hibernate / JPA создаются таблицы. Это более просто и, вероятно, создаст лучшую объектную модель (поскольку вы создаете ее напрямую). Но вы все равно должны иметь в виду, что вы создаете таблицы БД, поэтому вам следует подумать и о нормализации БД и т. Д.
2. Сначала вы будете использовать подход с таблицами при отображении какой-либо устаревшей схемы, когда у вас нет выбора, кроме как сделать это. Объектная модель может быть немного неуклюжей ...

Но я повторяю, оба подхода верны, если вы больше инженер БД, чем программист Java, вы, вероятно, сделаете 2), потому что это может быть более естественным для вас. Я, как программист на Java, делаю (почти) всегда 1) ...

Вы можете получить одинаковые результаты с обоими подходами, и в обоих вы должны подумать о том, что сгенерирует для вас спящий режим ...

Answer 2

Это не имеет никакого значения: один из них сопоставим с другим, но вы должны знать оба (несоответствие импеданса ORM).

Если вы занимаетесь разработкой новых полей, IMOперейти из диаграммы классов => таблицы БД;на уроках легче думатьВ целом, рациональные структуры классов хорошо отображаются на таблицы БД, но имейте в виду эффективность (часть «быть в курсе»).

Answer 3

Я думаю, что очень важно четко идентифицировать ваши сущности и отношения между ними, поскольку они представляют ваше представление в мире Java о реальной проблеме в мире доменов. Убедитесь, что у ваших организаций есть корреспондент в деловом плане. Фактически, это целая проблема с несколькими подходами (например, DDD). После того, как сущности будут четко определены, вы должны также рассмотреть, какова основная цель вашего приложения. Основываясь на этом, вы можете отобразить его по-другому в режиме гибернации.

Например, уровень сохраняемости, оптимизированный для чтения, может использовать менее нормализованную структуру БД, где небольшая избыточность может дать вам дополнительную скорость. В терминах Hibernate это означает выбор подходящего отображения наследования Hiberante для вашей иерархии объектов (если он у вас есть) или, возможно, использование выборочных объединений для массового чтения. Коллекции с отложенной загрузкой также могут помочь, но, опять же, это можно сделать после того, как вы определили свои сущности.

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

Сохраняйте отношения между сущностями простыми, избегайте двунаправленных связей, если это возможно.

Не уверен, что этот пост действительно вам нужен - суть в том, чтобы, по крайней мере, для начинающего, начать с классов, сделать его простым (однонаправленным) и убедиться, что вы не отображаете вещи без бизнеса Смысл, если вы действительно - действительно должны!

Answer 4

Я должен не согласиться с другими ответами, вы должны стремиться принять первый подход к модели базы данных в целом (хотя могут быть особые тривиальные случаи, когда первый подход к объектной модели лучше).

Реляционная модель давно пришла на смену сетевой модели (ОО, графовые базы данных) и иерархической модели (JSON, XML), что дает преимущества перед другими данными.представления, даже если модели могут быть технически преобразованы друг в друга.В долгосрочной перспективе гораздо проще разработать хорошо спроектированную, нормализованную схему, используя DDL вашего поставщика базы данных, чем выяснять, как генерировать DDL и обновлять операторы из приращений вашей модели OO.

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

Я написал об этом более подробно здесь .