Struktura fasoli nośnej JSF (najlepsze praktyki)

Świetne pytanie. Bardzo cierpiałem z tym samym dylematem, kiedy przeniosłem się do JSF. To naprawdę zależy od twojej aplikacji. Jestem ze świata Java EE, więc polecam mieć jak najmniej logiki biznesowej w swoich podstawach, jak to możliwe. Jeśli logika jest czysto związana z prezentacją Twojej strony, dobrze jest mieć ją w fasoli zaplecza.

Wierzę, że jedną z (wielu) mocnych stron JSF jest fakt, że można wystawiać obiekty domeny bezpośrednio na zarządzanych fasolach. I dlatego zdecydowanie polecam podejście <:outputText value="#{myBean.anObject.anObjectProperty}" />, w przeciwnym razie robisz za dużo pracy dla siebie w ręcznym ujawnianiu każdej właściwości. Ponadto byłoby trochę bałaganu podczas wstawiania lub aktualizowania danych, jeśli zamkniesz wszystkie właściwości. Istnieją sytuacje, w których pojedynczy obiekt domeny może nie być wystarczający. W takich przypadkach przygotowuję ValueObject PRZED wystawieniem go na fasoli.

EDIT: właściwie, jeśli zamierzasz zamknąć każdą właściwość obiektu że chcesz ujawnić, polecam, aby zamiast związać komponenty UI do fasoli podkładu, a następnie wstrzyknąć zawartość bezpośrednio do wartości komponentu.

Jeśli chodzi o strukturę fasoli, punktem zwrotnym dla mnie było zignorowanie wszystkiego, co wiedziałem o tworzeniu aplikacji internetowych i rozpoczęcie traktowania ich jako aplikacji GUI. JSF dużo naśladuje Swing i dlatego najlepsze praktyki tworzenia aplikacji Swing będą miały zastosowanie głównie do budowanie aplikacji JSF.

Mogę nie odpowiedzieć na każde twoje pytanie, ponieważ niewiele wydaje się zależeć od każdego przypadku.

• To dobrze mieć logikę biznesową w swojej fasoli. To zależy, skąd pochodzisz. Jeśli ćwiczysz projektowanie oparte na domenie, będziesz kuszony, aby włączyć logikę biznesową do backing bean lub może być również logiką wytrwałości. Twierdzą, że dlaczego tak głupi obiekt. Obiekt powinien nosić nie tylko stan, ale również zachowanie. Z drugiej strony, jeśli rozważysz tradycyjny sposób robienia rzeczy w Java EE, możesz mieć ochotę na dane w swojej fasoli wspierającej, która również może być twoją fasolą entity oraz inną logiką biznesową i wytrwałości w jakiejś fasoli sesji lub czymś takim. To też jest w porządku.

• Doskonale jest mieć pojedynczą fasolę na całej stronie. Nie widzę z tym problemu. To może nie wyglądać dobrze, ale to zależy od sprawy.

• Twoje drugie pytanie jest znacznie bardziej zależne od przypadku, w którym jesteś mając w ręku. Wolałbym iść domeny napędzane tutaj, może być właściwe, aby dodać właściwości do istniejących lub w inny sposób utworzyć nową fasolę dla tego. Co zawsze pasuje lepiej. Nie sądzę, żeby była do tego jakaś Srebrna kula.

• Jakie właściwości należy do jakiej fasoli podkładowej. Czy to nie zależy od obiektu domeny? A może pytanie nie jest takie jasne.

Co więcej, w podanym przykładzie kodu nie widzę żadnej ogromnej korzyści.

Myślę, że najważniejszą rzeczą z Twoim wsparciem jest oddzielenie ich logiki. Jeśli masz stronę główną dla systemu CMS, to uznałbym za złą praktykę umieszczanie każdego fragmentu kodu w jednej fasoli, ponieważ:

1. fasola w końcu stanie się bardzo duża
2. łatwiej jest innym znaleźć to, czego szukają, jeśli rozwiązują problemy ze stroną logowania, jeśli mogą łatwo wyszukać loginBean.plik java.
3. czasami masz małe kawałki funkcjonalność, która wyraźnie różni się od reszty kodu, oddzielając to, wyobrażam sobie, że ułatwiłbyś sobie przebudowanie / rozszerzenie tego kodu na coś większego, gdy masz już ładną fasolę o dobrej strukturze.
4. posiadanie 1 big bean, aby zrobić to wszystko, sprawi, że będzie bardziej zależny od pamięci, jeśli / kiedy musisz zrobić deklaracje takie jak mybigbean bigBean = new mybigbean (); zamiast używać funksjonality, którego potrzebujesz, wykonując loginbean loginBean = new LoginBean (); (popraw mnie jeśli się mylę tutaj???)
Moim zdaniem oddzielanie fasoli jest jak oddzielanie metod. Nie chcesz 1 dużej metody, która obejmuje ponad 100 linii, ale raczej podziel ją na nowe metody, które obsługują ich konkretne zadanie.
5. pamiętaj, najprawdopodobniej ktoś inny niż ty będzie musiał również pracować nad twoimi projektami JSF.

Tylko moje 2 centy na ten temat, nawet z pytaniem oznaczonym już jako odpowiedź.

Nie musiałbym trzymać tylko jednej fasoli na stronie. To zależy od funkcjonalności, ale przez większość czasu miałem jedną fasolę na stronę, ponieważ głównie jedna strona obsługuje jedną funkcjonalność. Na przykład na stronie mam link do rejestracji (będę link z RegisterBean) i link do koszyka zakupów (ShoopingBasketBean).

Używam tego<:> ponieważ zwykle podtrzymuję beans jako action beans, który przechowuje obiekt danych. Nie chcę pisać wrapper In My backing bean to access the properties of my data objects.

Lubię testować kod biznesowy bez widoku, więc BackingBeans traktuję jako interfejsy z widoku do kodu modelu. Nigdy nie umieszczam żadnych reguł ani procesów w BackingBean. Ten kod trafia do Usług lub pomocników, umożliwiając ponowne użycie.

Jeśli używasz walidatorów, umieść je z BackingBean i odwołaj się do nich z metody walidacji.

Jeśli masz dostęp do DAOs do wypełniania Selektów, Radia, Checkboxów, rób to zawsze z BackingBean.

Uwierz mi!. Można wstrzyknąć JavaBean do BackingBean, ale spróbuj wstrzyknąć BackingBean do innego. Wkrótce będziesz w niezłym zakresie konserwacji i zrozumienia kodu.