JSF2 - поддерживается EJB или ManagedBean?

Question

Когда я изучал JSF2, я понял, что не уверен, какими должны быть компоненты поддержки. С точки зрения дизайна, в чем разница между EJB и @ManagedBeans?

В конце я собираюсь использовать JPA, поэтому EJB - естественный выбор для бизнес-уровня. Является ли хорошей практикой использование EJB напрямую из JSF (как объяснено здесь )?

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

Это хороший дизайн? Должен ли я использовать @ManagedBeans для всех базовых компонентов для разделения чистых слоев, даже если в некоторых случаях они делегируют только EJB?

Answer 1

Очень правильный вопрос, но я думаю, что ответ зависит от "строгости" подхода к вашему проекту. Действительно, существует некоторая избыточность между компонентом поддержки JSF и EJB, поскольку оба реализуют некоторую бизнес-логику.

При идеальном использовании функций JSF с converters, rendered, validator и т. Д. Компонент поддержки может действительно быть чистым кодом бизнес-логики. Но на практике некоторая логика, связанная с представлением, часто в ней просачивается.

Эта логика, связанная с представлением, в идеале не должна быть в EJB. Эта логика, связанная с представлением, может зависеть от пакета лиц, но не обязательно. То, что он делает , делает его презентацией связанным или нет.

У унифицированной компонентной модели есть некоторые преимущества. И это подход, принятый Шов и Весна . В обоих случаях бизнес-компонент с декларативной транзакцией и т. Д. Может использоваться непосредственно в JSF (Spring не использует EJB, но предоставляет аналогичную модель). EJB пурист, однако, сказал бы, что вы должны разделить их.

Так что для меня это в конечном итоге вопрос вкуса и размера проекта. Я могу представить, что для небольшого / среднего проекта использование EJB в JSF работает нормально. Для больших проектов, где эта строгость имеет решающее значение, убедитесь, что вы не привинчиваете слои.

Answer 2

В Java EE 6 существует некоторое перекрытие между различными управляемыми bean-компонентами: управляемые bean-компоненты JSF (@ManagedBean), управляемые bean-компоненты CDI (@Named) и EJB-компоненты (@Stateless, @Statefull, @Singleton).

В слое вида я не вижу особых преимуществ для использования с @ManagedBean.Вариант CDI @Named, по-видимому, способен делать то же самое и больше, например, предоставить вам доступ к области преобразования.

В настоящее время кажется, что в настоящее время компонентная модель EJB также будет модифицирована какнабор аннотаций CDI.На это часто намекает особенно экспертная группа Реза Рахман.См., Например, Внедрение зависимостей в Java EE 6 - Часть 1

Пока этого не произошло, поэтому EJB-бины остаются самым простым местом для размещения бизнес-логики, особенно когда JPA используется дляпостоянство.

Тем не менее, независимо от того, получит ли CDI возможности EJB, ИМХО, все еще рекомендуется использовать отдельный компонент для концепции «поддерживающего компонента» и отдельный компонент для «бизнес-логики».

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

Службы (бизнес-логика) не должны ничего знать о какой-либо конкретной презентации.Они должны одинаково хорошо использоваться с компонентами поддержки JSF, JAX-RS, сервлетами, автономными удаленными клиентами Java SE или чем-то еще.

Даже если все бины станут бобами CDI, это не изменит этого основного разделения ответственности.

Answer 3

Интересная статья, не знал об этом. Тем не менее, для меня эта статья пахнет как разглагольствование по отношению к бобам, управляемым JSF. Он также тесно связан с EJB с JSF. Это может быть интересно в небольших (личных) приложениях, но, вероятно, не в реальных SOA-приложениях, где вы хотели бы иметь полный контроль над обслуживаемым EJB-компонентом.

Что касается того, что использовать для чего, я бы просто использовал @ManagedBean для обозначения модели JSF, которая связана с одним или несколькими конкретными представлениями JSF. Вы можете прекрасно использовать @EJB s для бизнес-логики, не относящейся к JSF, и / или моделей данных. Вы можете внедрить @EJB s в модель JSF и делегировать ее в методы действия и, возможно, также получить / установить, но вы не должны делать наоборот, т.е. не определять модель JSF в @EJB, это приводит тесная связь и сделает @EJB s непригодным для использования вне контекста JSF. Пока что ваш дизайн звучит хорошо, пока вы смотрите, чтобы ничего не импортировать из пакета javax.faces в классе @EJB.

Answer 4

Вызывая EJB из вашего XHTML, вы вводите тесную связь между выбором реализации в представлении и бизнес-уровнем.

Если вы используете управляемый bean-компонент для вызова EJB-компонента [или даже для добавления бизнес-делегата], вы сможете полностью изменить бизнес-уровень на Spring, не затрагивая слой представления (XHTML).

Это технически возможно, и вам очень легко (JSR 299) использовать EJB в качестве вашего управляемого компонента, и это, вероятно, то, что эти производители хотят, чтобы вы делали - привязались к специфике. Но правильно ли это делать? - №