Почему я не должен использовать бин JSF SessionScoped для логики?

Question

Я занимаюсь разработкой веб-приложения java EE с использованием JSF со стилем корзины покупок, поэтому я хочу собрать пользовательский ввод на нескольких страницах, а затем что-то сделать с ним.

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

1) Почему он называется сессионным компонентом, насколько я понимаю, он не имеет ничего общего с сеансом, я мог бы добиться того же, сохраняя в сеансе pojo.

2) Какой смысл быть в состоянии ввести его, если все, что я собираюсь ввести, - это новый экземпляр этой SFSB, тогда я мог бы также использовать pojo?

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

Я могу установить bean-объект области действия JSF в качестве управляемого свойстваиз всех моих bean-компонентов запроса, что означает, что он внедряется в них, но в отличие от SFSB, bean-объект управляемой сессии JSF привязан к сеансу http, поэтому один и тот же экземпляр всегда внедряется, пока сеанс http не был аннулирован.

Таким образом, у меня есть несколько уровней

1-й уровень) JSF-управляемые объекты EJB, имеющие дело с презентацией, по 1 на страницу.
2-й уровень) JSF-управляемый сеанс scbean-компонент oped, в котором установлены значения с помощью bean-компонентов запроса.
3-й уровень) EJB сеанса без сохранения состояния, который выполняет логику для данных в bean-объекте области сеанса JSF.

Почему это так плохо?

Альтернативный вариант - использовать SFSB, но затем мне нужно внедрить его в исходный объект bean-компонента, а затем сохранить его в сеансе http и вернуть обратно вкаждый последующий компонент запроса - просто кажется беспорядочным.

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

Любые мысли оценены Я чувствую, что я борюсь с этой технологией, а не работаю с ней.

Спасибо

Answer 1

Почему он называется сессионным компонентом, поскольку, насколько я понимаю, он не имеет ничего общего с сеансом, я мог бы добиться того же, сохраняя pojo в сеансе.

Из старого учебника по J2EE 1.3 :

Что такое сессионный компонент?

Сессионный компонент представляет собой один клиент внутри сервера J2EE. к получить доступ к развернутому приложению на сервере клиент вызывает методы сессионного компонента. Сессия Бин выполняет работу для своего клиента, защита клиента от сложности выполняя бизнес-задачи внутри сервер.

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

Так что это связано с "сессией". Но сессия не обязательно означает «HTTP сессия»

Какой смысл в том, чтобы вводить его, если все, что я собираюсь вводить, - это новый экземпляр этого SFSB, тогда я мог бы также использовать pojo?

Ну, во-первых, вы не внедряете SFSB в компонент без сохранения состояния (инъекция в другую SFSB будет в порядке), вам нужно выполнить поиск. Во-вторых, выбор между HTTP-сессией и SFSB действительно зависит от вашего приложения и ваших потребностей. С чисто теоретической точки зрения сеанс HTTP следует использовать для состояния логики представления (например, когда вы находитесь в многостраничной форме), а SFSB - для состояния бизнес-логики. Это хорошо объясняется в «старых» HttpSession v.s. Сеансовые компоненты с состоянием поток на TSS, который также имеет хороший пример, где SFSB имеет смысл:

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

Веб-сессия отслеживает состояние где пользователь находится на странице HTML течь. Однако, если пользователь затем получил доступ к системе через другой канал, например, WAP-телефон, или через колл-центр вы все равно хочу узнать состояние билета сделка покупки.

Но SFSB не просты, и если у вас нет необходимости обосновывать их использование, мой практический совет будет придерживаться HTTP-сессии (особенно, если все это для вас ново). На всякий случай см .:

• Java-компоненты Enterprise с сохранением состояния и состоянием
• Stateful EJB в веб-приложении?

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

Это не бизнес-логика, это логика представления.

Итак, у меня есть несколько уровней (...)

Нет. Вероятно, у вас есть уровень клиента, уровень представления, бизнес-уровень, уровень данных. То, что вы описываете, больше похоже на слои (даже не уверен). См:

• Кто-нибудь может объяснить эти слова: Уровень представления, Бизнес-уровень, Уровень интеграции в Java EE с примером?
• Spring, Hibernate, Java EE в 3-х уровневой архитектуре

Почему это так плохо?

Я не знаю, я не знаю, о чем вы говорите :) Но вам, вероятно, следует просто собрать информацию о многостраничной форме в компонент SessionScoped и вызвать Session Bean ( SLSB) в конце процесса.

Answer 2

1) Почему он называется сессионным компонентом, насколько я понимаю, он не имеет никакого отношения к сеансу, я мог бы добиться того же, сохраняя в сеансе pojo.

Исправление: сеанс EJB не имеет ничего общего с сеансом HTTP. В EJB, грубо говоря, клиент - это контейнер сервлетов, а сервер - это EJB-контейнер (оба работают на сервере веб-приложений). В HTTP клиент является веб-браузером, а сервер - сервером веб-приложений.

Имеет ли теперь смысл?

2) Какой смысл быть в состоянии ввести его, если все, что я собираюсь ввести, - это новый экземпляр этого SFSB, тогда я мог бы также использовать pojo?

Использование EJB для транзакционных бизнес-задач. Используйте управляемый сессионный компонент для хранения данных, специфичных для сеанса HTTP. Кстати, ни то, ни другое не является POJO. Просто Javabeans.

Почему я не должен использовать бин JSF SessionScoped для логики?

Если вы не пользуетесь транзакционными бизнес-задачами и абстракция, которую EJB предоставляет для этого, то просто выполнение этого в простом управляемом компоненте JSF действительно является неплохой альтернативой. Это также нормальный подход в базовых приложениях JSF. Однако действия обычно должны выполняться в управляемом компоненте, определяемом запросом, в котором объект в рамках сеанса вводится как @ManagedProperty.

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

Answer 3

На всякий случай, если вы не знаете об этом, и в качестве небольшого вклада в ваши ответы, вы действительно можете аннотировать SFSB с @SessionScoped, а CDI будет обрабатывать жизненный цикл EJB ... Это будет привязать EJB к Http-сессии, которой управляет CDI. Просто сообщаю, потому что в своем вопросе вы говорите:

but my research leads me to believe that a SFSB is not tied to a client's http session, so I would have to manually keep track of it via an httpSession, some side questions here . . .

Кроме того, вы можете делать то, что предлагаете, но это зависит от ваших требований: пока компоненты CDI не получат декларативную поддержку транзакций или расширенный контекст персистентности и т. Д., Вы обнаружите, что пишете много стандартного кода, который сделает ваш компонент менее чистым , Конечно, вы также можете использовать фреймворки, такие как Seam (теперь переходящий на DeltaSpike ), чтобы расширить определенные возможности ваших бинов через их расширения.

Так что я бы сказал, да, на первый взгляд вы можете почувствовать, что нет необходимости использовать EJB с сохранением состояния, но некоторые варианты использования могут быть лучше решены через них. Если пользователь добавляет продукт в свою корзину, а другой пользователь добавляет этот же продукт позже, но на складе есть только одна единица, кто получит его? тот, кто делает заказ быстрее? или тот, кто добавил это первым? Что если вы захотите получить доступ к своему менеджеру сущностей для сохранения карты в случае, если пользователь решит случайно закрыть свой браузер, или что если у вас есть транзакции, которые порождают несколько страниц, и вы хотите, чтобы каждый шаг был синхронизирован с БД? (Держать транзакцию открытой так долго не рекомендуется, но, возможно, может быть такой сценарий, когда это необходимо?) Вы можете использовать SLSB, но иногда лучше и чище использовать SFSB.