Как моделировать Java EE?

Question

Предположим, что я решил пойти со стеком Java EE для своего корпоративного приложения.

Теперь, для моделирования домена (или: для проектирования M MVC), какие API-интерфейсы я могу с уверенностью предполагать и использовать, и от чего я должен держаться подальше от ... скажем, через слой абстракции?

Например,

1. Должен ли я идти вперед и помет моя модель с призывами Hibernate/JPA API? Или я должен построить абстракцию ... свой собственный уровень сохранения, чтобы избежать жесткого кодирования этих двух конкретных API устойчивости? Почему я прошу об этом: Несколько лет назад появился этот API-интерфейс Kodo, который был заменен Hibernate. Если бы кто-то разработал слой сохранения и закодировал остальную часть модели на этом уровне (вместо того, чтобы заманивать модель вызовами к конкретному API-интерфейсу поставщика), это позволило бы (относительно) легко переключаться с Kodo на Hibernate на xyz.

2. Рекомендуется ли агрессивное использование * QL, предоставляемого поставщиком персистентности в вашей модели домена? Я не осведомлен о каких-либо реальных проблемах (например, производительности, масштабируемости, переносимости и т. Д.), Возникающих из-за интенсивного использования языка, подобного HQL. Почему я спрашиваю об этом: Я хотел бы как можно больше избежать написания собственного кода, когда то же самое можно было бы выполнить с помощью языка запросов, который более переносимый, чем SQL.

Извините, но я полный новичок в этой области. Где я могу найти дополнительную информацию по этой теме?

Answer 1

Вот что я считаю, это традиционный вид:

• Сущность в вашем проекте формирует модель предметной области. Они должны быть повторно использованы и не тесно связаны с технологией персистентности (я вернусь позже о жесткой и свободной связи)
• Бизнес-уровень использует модель домена, а также предоставляет услуги и другие продукты.
• Уровень доступа к данным отвечает за сохранение модели домена (объектов) в постоянном хранилище.

Объект не должен напрямую обращаться к уровню доступа к данным. Но бизнес-уровень будет таким образом, чтобы загружать и сохранять объекты модели домена.

Если карта, что технологии Java EE вы обычно что-то вроде:

• Entities -> POJO с Hibernate/JPA аннотации. Обратите внимание, что аннотации не подразумевают жесткой связи с JPA/Hibernate, тот же POJO может использоваться где-то еще без Hibernate.
• Бизнес слой -> Session EJB или Spring
• слой доступа к данным -> JPA/Hibernate

Это грубый набросок, и есть много возможных вариантов. Вы можете пропустить сессию EJB и реализовать бизнес-уровень другим способом. Вы также можете решить, чтобы бизнес-уровень вызывал сессию JPA/Hibernate Session/EntityManager напрямую, и в этом случае JPA/Hibernate действительно является DAL, или вы можете захотеть обернуть доступ к Session/EntityManager в так называемые объекты доступа к данным (DAO).

Что касается HQL, попробуйте придерживаться того, что переносимо, и если вы используете собственный SQL, следуйте соглашениям SQL-92. Если материал станет сложным, возможно, представите DAO. Таким образом, вы знаете, что единственное место, где есть запросы HQL, находится в DAO. Вы также можете сначала реализовать логику запроса «процедурно» в DAO, и если у вас есть проблемы с производительностью, повторите ее реализацию с помощью более сложного запроса HQL.

EDIT

Что касается ваших вопросов в комментарии:

Бизнес слоя зависит от уровня данных. Если вы хотите, чтобы бизнес-уровень не зависел от Hibernate/JPA, тогда ваш уровень данных должен соответствовать аннотация Hibernate/JPA. Если вы используете DAO для своего уровня данных, это будет так. DAO будет «тонким рукописным слоем персистентности над Hibernate» (чтобы взять ваши слова). Я бы представил DAO для всех сущностей в вашем случае.

Что вы задаете, это довольно общий вопрос дизайна. Я не могу дать окончательный рецепт для этого и не суммировать все варианты в одном ответе, поскольку это зависит от конкретного случая. Например, мы пока не говорили о проблеме транзакций, которую вы обычно начинаете с бизнес-уровня, но о том, что должен быть осведомлен об уровне данных. Это обычно зависит от используемых технологий и ваших требований.

Тем не менее, вот список ресурсов, которые могут быть заинтересованы в: книги Pattern of Enterprise Application Architecture, книга Real World Java EE Patterns - Rethinking Best Practices, книга Domain Driven Design и более конкретно модели Data Access Object, Repository pattern, Open Session in View (если это для веб-приложение), и возможно, Anemic Domain Model.

EDIT 2

Хорошо, еще несколько предложений о сделках:

Сделки должны концептуально управляться в бизнес-уровне; определение того, что должно быть сделано в одной единице работы, чтобы быть последовательной, действительно зависит от самой логики приложения.

С EJB3 транзакции могут быть объявлены аннотациями и приложением. сервер управляет этим для вас. Для получения дополнительной информации см. this other answer. С весной вы также можете отметить транзакции декларативно, но я не знаю деталей. В противном случае вам нужно будет начать/остановить транзакцию самостоятельно.Это будет немного отличаться от того, используете ли вы транзакции JDBC или транзакции JTA.

Сделки также относятся к ленивой загрузке в спящем/JPA. Объект, который был ленивым загружен, действительно может быть загружен только в случае текущей транзакции. Если транзакции завершаются на бизнес-уровне, объекты, которые возвращаются на уровень представления, должны быть загружены с высокой нагрузкой.

Чтобы обойти эту проблему, популярным образцом для веб-приложений является Open Session in View, о котором я уже упоминал. В этом случае слой презентации запускает/останавливает транзакции (что немного неверно концептуально), но отлично работает с ленивой загрузкой.

Answer 2

Ваша модель домена и его уровень сохранения должны теоретически быть раздельными - нет необходимости в классе Entity, чтобы узнать что-либо о том, как и как он сохраняется, поэтому вы можете использовать что-то вроде Hibernate для создания уровня персистентности без загрязнения сами классы модели домена. Вы не «кодируете модель [...] против этого слоя» - вы кодируете модель, а затем сопоставляете ее с постоянным хранилищем с каким-то уровнем ORM, где модель домена не зависит от уровня ORM. Очевидно, что уровень сохранения будет зависеть от модели домена, но это нормально.

Я лично борется за использование слишком большого количества HQL с (N) спящего режима по той причине, о которой вы просите, но бывают случаи, когда это неизбежно. Вы уже знаете, и сами подчеркнули, что главный вопрос там, так что вы вряд ли будете злоупотреблять этим в любом случае.