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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 2

Это просто вопрос дизайна между состоянием и безгосударственной архитектурой.

В большинстве случаев дизайн без гражданства предпочтительнее, так как это проще.

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

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

bean - это способ сделать это. Весенний прототип или веб-фасоль.

проверка тоже вне jboss шов структура.