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

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

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

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

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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

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

Тем не менее, независимо от того, получит ли CDI возможности EJB, имхо по-прежнему лучше использовать отдельный bean для концепции "поддержки bean" и отдельный bean для "бизнес-логики",.

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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