Wpis z mikrobloga

Po godzinach męczenia się by jakoś tony logiki w jsf beanach podpiąć do ejb beanów, radzę by nikomu nie przyszło do głowy umieszczać logiki w jsf beanach czy innych beanach stricte powiązanych z frameworkiem. Niestety w projektach studentów i jednej z największym firmy konsultingowej na świecie to nagminne.

Korzyści z stosowania się do tej reguły: przeżyjesz release w nienaruszonym stanie.

Teoretycznie ejb -> jsf bean niewykonalne (zwłaszcza poza http request np. timeout na singletonie - scheduler).
Praktycznie - trzeba wystawić webservice (w jsf ofc.) poprzez które odwołasz się z ejb.

#programowanie #zasady #przedszkole #kodowanie
  • 8
@kapelusz: tzn. @Singleton @Startup @Timeout odp. crona w J2EE. Niestety FacesContext istnieje tylko jeśli istnieje aktualnie przetwarzane http query, ejb container jest niezależne od http query. Jsf pooling nie mógł być (zasadniczo rozwiązanie wykonałem praktyczne - webservice), bo bez interakcji z użytkownikiem kod by nie działał poza tym.

JSF kompletnie nie nadaje się do robienia backgroundowego przetwarzania itd. #dobrarada
@glosno: no tak zgadza się ale widział bym to tak że po stronie klienta jak jest otwarta stronka to w JS co np. 30 sekund odpala się AJAXem zapytanie do JSF Beana o stan taska, a JSF Bean odpytuje EJB
Pracuję w firmie zależnej od jednej z większych grup finansowych. Zapytam się przekornie, czy wybrałbyś bank który żeby transfer wykonał się musisz na noc zostawić otwartą sesję?
@kapelusz: ale logika w ejb odwołuje się do czegoś co nie może żyć poza http query. Scope EJB jest zgoła odmienny od JSF a poza beany z logiką to dwa różne kontenery. Logika w JSF beanach jest praktycznie bezwartościowa dla EJB. Coś takiego szybko prowadzi do Copy & Pastingu. Zauważ że w aplikacjach bankowych prawie nigdy nie tworzysz aplikacji od nowa, tylko dopisujesz kod do istniejącej - przepisanie na nowo jest