Witam
Jeśli można to mam kilka pytań odnośnie JEE i niekoniecznie ver. 6 :
I.Ostatnio wyczytałem taki fragment:
Aplikacja webowa korzystająca z beana, który wstrzykuje inną klasę beana, wymaga, aby bean ten był w stanie zapamiętać swój stan na czas interakcji użytkownika z aplikacją. Sposobem na zdefiniowanie tego stanu jest nadanie beanowi zasięgu. W zależności jak używasz danego obiektu, możesz nadać mu jeden z zasięgów.
I tu mamy: żądanie, sesja, aplikacja , zależność (default), konwersacja.
O ile dobrze rozumiem to jest tak .
1.Żądania (@RequestScope) czyli wykonanie w odpowiedzi na pojedyncze wywołanie żądania HTTP. Czyli klient wysyła żądanie i za każdym razem wykonywana jest logika zawarta w danym beanie.
2.Sesji (@SessionScoped) Interakcja w czasie wielokrotnych żądań HTTP danego klienta. Czyli jak mniemam stan jest zapisywany pomiędzy kolejnymi żądaniami http danego klienta. Czyli inaczej mówiąc obiekt ten jest powiązany jak sama nazwa mówi z sesją http request. Nie rozumiem jaka jest różnica w stosunku do wykorzystania tego beana a zapisania jakiegoś obiektu/wartości
w obiekcie sesji danego klienta ??? Rozumiem że powinniśmy użyć tego typu beana jeśli np. chcielibyśmy przetrzymać ustawienia personalizacyjne danego użytkownika odnośnie aplikacji ??
-
Aplikacji @ApplicationScoped. Czyli stan współdzielony w czasie wszystkich interakcji użytkowników (liczba mnoga) z aplikacją webową. Kurcze więc teraz tak może z głupia ale czym to się różni od singletona ?? Chodzi mi dokładnie o obiekt @Singleton przecież też przetrzymuje on stan dla wszystkich klientów ?? Jedyna różnica jaką widzę to to iż @Singleton posiada dodatkową adnotacje @Startup. Czy jak użyjemy ApplicationScoped to mamy tylko 1 instancje beana ,czy jest jakaś pula czy coś ???
-
Zależności @Dependent (zasięg domyślny)Obiekt służący tylko 1 klientowi ma taki sam czas trwania. Czym to się będzie różnić w takim razie od zasięgu żądania ??
-
Konwersacji @ConversationScoped. Rozumiem iż jest on podobny do session scoped jednak odnosi się do interakcji użytkownika z JSF, nie bardzo mogę pojąć ten zasięg, może dlatego iż nigdy nie miałem przyjemności używać jsf :/
II.Ogólnie mam też taki przypadek w aplikacji, że każdy użytkownik który zaloguje się do systemu ma jakieś ustawienia personalizacyjne które może sobie w każdym czasie zmieniać. Teraz jest tak, że za każdym razem czyli wywołaniem zapytania HTTP te ustawienia są sprawdzane odczytywane. Dlatego myślałem, o użyciu 3 różnych rzeczy.
- zapisać ustawienia w obiekcie sesji danego użytkownika
- zapisać ustawienia w cookies
- przetrzymywać ustawienia w beanie sessionscoped.
Jeśli chodzi o sposób 3 to myślałem o czymś takim :
@SessionScoped
public class PersonalizationBean implements Serialization {
@Inject @Personalization Instance<PersonSettings> personSettings;
...
}
Nie wiem który ze sposobów byłby najlepszy w moim przypadku ??
Zmiany personalizacyjne dotyczą w moim przypadku wyglądu aplikacji czyli defacto po zaakceptowaniu nowych zmian cała aplikacja jest odświeżana.
III. Jakoś nie mogę znaleźć potrzeby istnienia w aplikacjach JEE stanowego komponentu sesyjnego. Wszyscy piszą aby wystrzegać się tego typu konstrukcji. W systemach rozproszonych komponent ten musi być replikowany , przetrzymuje stan tylko 1 klienta itd itp.
Nie jestem jakoś super doświadczony w jee i to co się wyczyta w książkach na stronach to jedno a to co ma się w głowie to drugie :)
Z tego co widziałem w aplikacjach to rzeczywiście nie widziałem ani 1 stanowego komponentu sesyjnego. Zresztą po co go używać przecież można użyć inne rozwiązania ja np widziałem w aplikacji gdzie wykonywany był bezstanowy komponent sesyjny a stan był zapisywany w bazie. Gdy była wywoływana metoda w tym komponencie sprawdzany był stan i następnie wykonywana metoda.
Można także użyć obiektu sesji danego klienta czy też beana sesyjnego. To wszystko tworzy pewnego rodzaju zagmatwanie.
Oliwy do ognia dolewają jeszcze aplikacje które się przegląda , a informacje które się przeczytało. Podam taki klasyczny przykład, np o obiekcie HttpSession i takim przykładem jest koszyk z zakupami gdzie piszą aby te informacje przechowywać w tym obiektem gdzie stan zakupów danego klienta jest przechowywany na czas trwania jego sesji co wydaje się być logiczne. Następnie gdzieś w kodzie widzi się, że zaimplementowane są metody dodawania artykułów i wykorzystany jest bezstanowy komponent sesyjny który zapisuje dane pozycje w bazie, czyli wiąże danego usera z produktami na dany dzień. Wtedy człowiek się zastanawia hmm no jest to też rozwiązanie ale dlaczego akurat takie, czy jest lepsze, czy tak się to powinno robić czy w publikacjach w książkach piszą bzdury, czy po prostu ten programista źle napisał ????
Tego typu np rozwiązania dodają do tego całego jee dodatkowe pytania, po co w takim razie jest obiekt http session, czy zamiast tego nie lepiej użyć stanowego komponentu sesyjnego i tam zapisywać informacje ??
Na koniec nie chciałbym być źle zrozumiany tylko w różnych publikacjach jak czyta się o jee jest to wszystko tak fajnie wypunktowane natomiast jak tak człowiek się zastanowi to czasami mam wrażenie takiego mętliku, pojawiają się takie pytania typu a po co, a dlaczego tak czy nie da się lepiej, czy jeśli użyję tego do takiego typu rozwiązań to dobrze czy źle .....
Przepraszam jeśli nie bardzo skonkretyzowałem moje pytania. Chciałem jakoś w punktach zaznaczyć ważniejsze zagadnienia. Dziękuję za odpowiedzi...