Właśnie zacząłem czytać Core JavaServer Faces, 3rd Ed. i mówią tak (moje podkreślenie):

To historyczny przypadek, że istnieją dwa oddzielne mechanizmy, fasola CDI i fasola zarządzana przez JSF, dla komponentów bean, które mogą być używane na stronach JSF. Sugerujemy użycie fasoli CDI, chyba że aplikacja musi działać na zwykłym programie uruchamiającym serwlet, takim jak Tomcat.

Czemu? Nie podają żadnego uzasadnienia. Używałem @ManagedBeanwszystkich fasoli w prototypowej aplikacji działającej na GlassFish 3 i tak naprawdę nie zauważyłem żadnych problemów z tym. Nie mam nic przeciwko migracji z @ManagedBeando @Named, ale chcę wiedzieć, dlaczego powinienem się tym przejmować .

CDI jest preferowane w stosunku do zwykłego JSF, ponieważ CDI umożliwia wstrzykiwanie zależności w całym JavaEE. Możesz także wstrzyknąć POJO i pozwolić im zarządzać. Dzięki JSF możesz wstrzyknąć tylko podzbiór tego, co możesz za pomocą CDI.

Użyj CDI.

Zgodnie z JSF 2.3 @ManagedBeanjest przestarzałe . Zobacz także wydanie specyfikacji 1417 . Oznacza to, że nie jest już powodem do wyboru @ManagedBeanponad @Named. Zostało to po raz pierwszy wdrożone w Mojarra 2.3.0 w wersji beta m06.

Historia

Podstawowa różnica polega na tym, że @ManagedBeanjest zarządzana przez framework JSF i jest @ManagedPropertydostępna tylko dla innego zarządzanego komponentu bean JSF. @Namedjest zarządzany przez serwer aplikacji (kontener) poprzez CDI ram i jest poprzez @Injectdostępny na każdym rodzaju pojemnika zarządzanej artefaktu jak @WebListener, @WebFilter, @WebServlet, @Path, @Stateless, etc a nawet JSF @ManagedBean. Z drugiej strony w sprawie, @ManagedPropertyczy nie działa Wewnątrz @Namedlub innego pojemnika zarządzanej artefaktu. Działa naprawdę tylko wewnątrz @ManagedBean.

Inną różnicą jest to, że CDI faktycznie wstrzykuje serwery proxy delegujące do bieżącej instancji w zakresie docelowym na podstawie żądania / wątku (tak jak w przypadku wstrzykiwania EJB). Mechanizm ten pozwala na wstrzyknięcie ziarna o węższym zakresie do ziarna o szerszym zakresie, co nie jest możliwe w przypadku JSF @ManagedProperty. JSF „wstrzykuje” tutaj fizyczną instancję bezpośrednio, wywołując metodę ustawiającą (dokładnie dlatego jest ona wymagana, podczas gdy nie jest to wymagane w przypadku @Inject).

Chociaż nie jest to bezpośrednio wada - są inne sposoby - zakres @ManagedBeanjest po prostu ograniczony. Z drugiej strony, jeśli nie chcesz narażać się na zbyt wiele @Inject, możesz po prostu zatrzymać zarządzaną fasolę @ManagedBean. To jak w protectedporównaniu public. Ale to się nie liczy.

Przynajmniej w JSF 2.0 / 2.1 główną wadą zarządzania komponentami typu bean obsługującymi JSF przez CDI jest brak odpowiednika formatu CDI @ViewScoped. @ConversationScopedZbliża, ale nadal wymaga ręcznego uruchamiania i zatrzymywania i dołącza brzydki cidparametr zapytania do adresów URL wyniku. MyFaces CODI ułatwia to poprzez w pełni przezroczyste mostkowanie JSF javax.faces.bean.ViewScopeddo CDI, więc możesz to zrobić @Named @ViewScoped, jednak dołącza to brzydki windowIdparametr żądania do URL-i wynikowych wyników, również w zwykłej nawigacji między stronami. OmniFaces rozwiązuje to wszystko za pomocą prawdziwego CDI, @ViewScopedktóry naprawdę wiąże zakres beana ze stanem widoku JSF zamiast z dowolnym parametrem żądania.

JSF 2.2 (który został wydany 3 lata po tym pytaniu / odpowiedzi) oferuje nową, w pełni kompatybilną z CDI @ViewScopedadnotację w wersji javax.faces.view.ViewScoped. JSF 2.2 jest nawet dostarczany z tylko CDI, @FlowScopedktóry nie ma @ManagedBeanodpowiednika, popychając tym samym użytkowników JSF w kierunku CDI. Oczekuje się, że @ManagedBeani znajomi zostaną wycofani zgodnie z Java EE 8. Jeśli nadal używasz @ManagedBean, zdecydowanie zalecamy przejście na CDI, aby przygotować się na przyszłe ścieżki aktualizacji. CDI jest łatwo dostępny w kontenerach zgodnych z Java EE Web Profile, takich jak WildFly, TomEE i GlassFish. W przypadku Tomcata musisz zainstalować go osobno, dokładnie tak, jak to zrobiłeś dla JSF. Zobacz także Jak zainstalować CDI w Tomcat?

W Javie EE 6 i CDI masz inną opcję dla Managed Beans

• @javax.faces.bean.ManagedBeanodnosi się do JSR 314 i został wprowadzony w JSF 2.0. Głównym celem było uniknięcie konfiguracji w pliku faces-config.xml w celu użycia ziarna na stronie JSF.
• @javax.annotation.ManagedBean(“myBean”) jest zdefiniowany przez JSR 316. Uogólnia on komponenty bean zarządzane przez JSF do użytku w innych miejscach w Java EE
• @javax.inject.Named(“myBean”) są prawie takie same, jak powyżej, z wyjątkiem tego, że do aktywacji CDI potrzebny jest plik beans.xml w folderze web / WEB-INF.

Używałem CDI w GlassFish 3.0.1, ale aby to zadziałało, musiałem zaimportować szkielet Seam 3 (Weld). To działało całkiem nieźle.

W GlassFish 3.1 CDI przestał działać, a Seam Weld przestał z nim działać. Otworzyłem błąd w tym, ale nie widziałem go jeszcze naprawionego. Musiałem przekonwertować cały mój kod na używanie adnotacji javax.faces. *, Ale planuję wrócić do CDI, gdy zaczną działać.

Zgadzam się, że powinieneś użyć CDI, ale jeden problem, którego nie widziałem jeszcze rozwiązany, dotyczy tego, co zrobić z adnotacją @ViewScoped. Mam dużo kodu, który od tego zależy. Nie jest jasne, czy @ViewScoped działa, jeśli nie używasz z nim @ManagedBean. Byłbym wdzięczny, gdyby ktokolwiek mógł to wyjaśnić.

Jeden dobry powód, aby przejść na CDI: możesz mieć wspólny zasób o zasięgu sesji (na przykład profil użytkownika), który byłby przypisany @Injectzarówno do komponentów bean zarządzanych przez JSF, jak i usług REST (np. Jersey / JAX-RS).

Z drugiej strony @ViewScopedjest to nieodparty powód, aby trzymać się JSF @ManagedBean- szczególnie w przypadku wszystkiego, co ma znaczący AJAX. W CDI nie ma standardowego zamiennika.

Wygląda na to, że może mieć pewne wsparcie dla @ViewScopedadnotacji typu a dla fasoli CDI, ale osobiście nie bawiłem się tym.

http://seamframework.org/Seam3/FacesModule