EJB с отслеживанием состояния в веб-приложении?

Я никогда не использовал EJB с отслеживанием состояния. Я понимаю, что EJB с отслеживанием состояния может быть полезен с java-клиентом.

Но мне интересно: в каком случае использовать их в веб-приложении? И как? Должны ли мы помещать эти bean-компоненты с сохранением состояния в сеанс (из-за http без сохранения состояния)?

Это хорошая практика? (без особых дискуссий о сохранении состояния и без сохранения состояния)


person Sebastien Lorber    schedule 11.05.2010    source источник


Ответы (1)


Как ни странно, это второй вопрос по SFSB и веб-приложениям на сегодняшний день, хотя эта тема обычно не так распространена.

в каком случае использовать их в веб-приложении?

Традиционным примером SFSB и веб-приложения является корзина для покупок. Но в то же время вы можете сделать то же самое с HttpSession.

В идеале если состояние относится к бизнес-логике, а не к логике представления, оно должно быть в SFSB. Но на практике люди обычно выступают против SFSB (из-за сложности, которую он вносит), если только они не предлагают то, что вы не можете легко сделать с HttpSession. В большинстве случаев вы можете настроить дизайн для хранения информации в HttpSession или базе данных и передавать ее без необходимости использования SFSB. Но в конечном итоге это вопрос чистоты дизайна.

И как? Должны ли мы помещать эти bean-компоненты с сохранением состояния в сеанс (из-за http без сохранения состояния)?

Модель EJB является более богатой, чем модель HttpSession, потому что EJB - это транзакционные компоненты, и есть явные обратные вызовы для пассивации и активации SFSB. Это связано с повышенной сложностью правильного использования SFSB, а именно (1) обработкой исключений и (2) параллелизмом и (2) удалением и тайм-аутом SFSB. Смотрите мои ответы здесь для более подробной информации:

Если вы хотите их использовать, вам нужно сначала найти SFSB, чтобы получить ссылку на один свежий удаленный экземпляр. Затем вам нужно будет где-то сохранить эту ссылку, чтобы можно было повторно использовать ее в запросах. Это где-то обычно HttpSession, что означает, что даже если вы используете SFSB, вы не можете полностью избавиться от него.

С помощью EJB2 удаленная ссылка, называемая handle, может быть сериализована для повторного использования позже. Тогда можно было сохранить if, например, в базе данных, хотя я никогда этого не видел. Я не знаю, возможно ли это еще с EJB3.

Это хорошая практика?

Как я уже сказал, люди обычно не рекомендуют этого, если вы точно не знаете, почему вы бы использовали их, а не HttpSession, и только если вы хорошо владеете моделью EJB. (SFSB может быть оправдан, например, если бизнес-сервис доступен через веб-интерфейс и настольный клиент). Многие другие фреймворки не имеют чего-то похожего на SFSB, и людям все еще удается создавать отличные приложения с ними.

PS: Я использовал SFSB в веб-приложении, и его действительно сложнее использовать, чем HttpSession, но в конечном итоге он сработал.

person ewernli    schedule 11.05.2010
comment
Еще одна причина для SFSB - воспользоваться преимуществом extended persistence context в JPA. Это сложная тема, и ее следует использовать умеренно, но если вам это нужно, это определенно причина для выбора SFSB. - person Arjan Tijms; 30.01.2011