Мы пишем один интерфейс DAO для каждой доменной модели? Если у нас есть
междисциплинарное поведение, когда участие включает более одного
Модель предметной области мы объявляем новой парой DAO интерфейс-реализация и вызываем
это соответственно? Как пример: «Заказы клиентов со склада, чеки со склада
Доступен ли пункт -> подтверждает, если он "куда это пойдет?"
Ты мог бы сделать это. Возможно, более простым способом было бы, чтобы Служба управляла вызовами DAO. Если вы используете Spring, вы можете определить границы транзакции для методов службы, поэтому все методы DAO будут участвовать в одной транзакции. Таким образом, ваши DAO остаются специфичными для своих соответствующих моделей, и в теории проще. Помните, что когда DAO сбрасывает сеанс, все изменения помещаются в базу данных. Так что, если у вас есть модели User и Profile, и они соответствующим образом отображаются в спящем режиме, если вы создадите экземпляр каждого и вызовете сброс сеанса, они оба будут сохранены.
Этот подход привлекателен, потому что DAO должны делать одну вещь - выполнять постоянные операции. Если вы начинаете создавать сложные DAO, вы можете инкапсулировать бизнес-требования вашего приложения в уровне постоянства, чего вы не хотите делать. Сервисы - это место, где можно заказать постоянные операции для реализации бизнес-требований.
Как Hibernate взаимодействует с MVC? Есть ли важные аспекты
быть в курсе?
MVC - это парадигма. Контроллер модельного вида. Цель состоит в том, чтобы определить четкие проблемы в вашем приложении, чтобы отдельные компоненты могли сосредоточиться на одной вещи. Например, объект Model не должен сообщать представлению о том, как визуализировать себя. Hibernate - это постоянная реализация ORM. Код гибернации - это один из способов сохранения объектов модели. MVC и hibernate очень мало связаны друг с другом, вы можете иметь MVC в приложении и не иметь Hibernate, или Hibernate в приложении и не иметь MVC.
Может быть, я не очень хорошо понимаю, что такое отдельные сущности?
Это те, которые мы вынули из контекста Hibernate - эффективно
просто коллекции классов?
Из документации"Отсоединено - отсоединенный экземпляр - это постоянный объект, но его Сессия закрыта."
Отдельные экземпляры могут быть сохранены позже, но их необходимо повторно связать с сеансом.
Если я хочу сделать уровень персистентности без ORM, просто с простым
JDBC, какие у меня проблемы? Я слышал, что Hibernate имеет некоторые умные
сеанс, который обрабатывает параллельные запросы, так что будет с
JDBC?
Основным недостатком является то, что вам необходимо преобразовать результаты jdbc в объекты, если ваше приложение использует объекты для представления сущностей. Вы также должны написать sql. Использование jdbc - неплохая идея. ОРМ это варианты. JDBC это еще один вариант. Вы также можете смешивать и сочетать, но это может быть сложно. Параллельные запросы в ваше приложение не должны быть проблемой вашего уровня персистентности. Просто убедитесь, что ваши DAO не сохраняют никакое состояние (то есть используют статические переменные), и у вас все будет хорошо.
Где находится бизнес-логика? Это DAOimpl классы?
Это комбинация модели вашего домена и ваших услуг. Как уже упоминалось, если вам нужно сохранить вещи по порядку, то можете перейти в сервис. Если у вас есть требование, что некоторые поля должны быть ограничены некоторыми значениями, это может быть в самой модели. Это НЕ в DAO - они должны справляться с настойчивостью.