Зачем использовать сессионные компоненты с отслеживанием состояния?

Я изучаю ejb3 и мне просто интересно, когда удобно использовать SFSB? Я не могу найти ни одного хорошего примера, когда SFSB действительно легко решает какую-то сложную проблему.

Вы имеете в виду, как тележку для покупок? Это очевидный ответ, который я могу придумать.

На самом деле я вижу, что SLSB можно использовать как веб-сервисы, и это удобно.

Вы можете рассматривать EJB как один из способов развертывания распределенных сервисов, но будьте осторожны. Термин «веб-службы» заставляет большинство людей думать о «веб-службах на основе SOAP, использующих протокол HTTP», а это не то, что у вас есть в SFSB.

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

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

Например, мы не можем использовать SFSB из SLSB, потому что объекты с отслеживанием состояния могут использоваться только из контекста с отслеживанием состояния.

Да, они дополняют друг друга. Вы используете SFSB для случаев, когда требуется - подождите, пока - состояние должно поддерживаться между вызовами.

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

Откуда здесь взялись сервлеты?

Единственная прибыль, которую я вижу в SFSB, - это управление транзакциями. Но я думаю, что это редкий случай, когда нам действительно нужна транзакция, а БД нам не нужна. Я могу предположить, что это может быть действительно полезно, когда мы храним наши данные в xml-файле и используем управление транзакциями в SFSB для моделирования нереляционной БД.

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

Я почти уверен, что ошибаюсь, поэтому приведите мне несколько действительно хороших примеров использования SFSB.

Чего ты ждешь? Это кто-то выложит рабочий SFSB? Я не собираюсь этого делать, в основном потому, что я не большой поклонник EJB. (Я делаю все, о чем вы говорите, и многое другое с помощью Spring.)

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

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

в большинстве случаев предпочтительнее использовать дизайн без сохранения состояния, поскольку он проще.

Хотя вначале это проще для понимания, создание приложений без сохранения состояния приводит к ряду проблем (множество веб-служб без сохранения состояния, синглтон Spring и т. д.), что делает приложение менее управляемым в долгосрочной перспективе.

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

Сессионный компонент с отслеживанием состояния - способ сделать это. Spring прототип или другой компонент с веб-областью видимости.

также ознакомьтесь с рамкой шва jboss.