Подтвердить что ты не робот

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

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

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

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

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

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

4b9b3361

Ответ 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

в большинстве случаев предпочтительнее, чем проще, чем проще.

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

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

stateful session bean - это способ сделать это. spring прототип или веб-область bean другая.

проверьте также фреймворк jboss.