Jakie są główne wady Java Server Faces 2.0?

Po 5 latach pracy z JSF, myślę, że mogę dodać moje 2 centy.

Dwagłówne wady JSF :

[[10]}Duża krzywa uczenia się. JSF jest złożony, to prawda.
1. jego składowa natura. Framework oparty na komponentach stara się ukryć prawdziwą naturę sieci, która wiąże się z ogromną ilością komplikacji i katastrof (jak np. brak wsparcia GET w JSF w ciągu prawie 5 lat).
   IMHO ukrywanie żądania/odpowiedzi HTTP od dewelopera jest ogromny błąd. Z mojego doświadczenia wynika, że każdy Framework oparty na komponentach dodaje abstrakcję do tworzenia stron internetowych, a ta abstrakcja powoduje niepotrzebne koszty ogólne i większą złożoność.

I drobne wady, które przychodzą mi do głowy:

1. domyślnie ID obiektu składa się z ID jego rodziców, na przykład form1: button1.
2. nie ma łatwego sposobu na skomentowanie błędnego fragmentu strony. Tag <ui:remove> wymaga poprawnej składniowo treści, która jest przetwarzana w każdym razie.
3. niskiej jakości komponenty stron trzecich, które np. nie sprawdzają isRendered() wewnątrz metody processXxx() przed kontynuowaniem.
4. włączenie LESS & Sencha jest trudne.
5. nie gra dobrze z odpoczynkiem.
6. nie jest to łatwe dla projektantów UX, ponieważ gotowe komponenty mają własne style CSS, które muszą zostać nadpisane.

Proszę spojrzeć na małą popularność Gobestry, Wicket i niski entuzjazm doświadczonych programistów JSF (co jest jeszcze bardziej znaczące). A dla kontrastu, spójrz na sukces Rails, Grails, Django, Play! Framework-wszystkie są oparte na działaniu i nie próbują ukrywać przed programistą prawdziwych żądań / odpowiedzi i bezpaństwowej natury sieci.

Kilka wad, które przychodzą na myśl:

1. JSF jest frameworkiem opartym na komponentach. Ma to nieodłączne ograniczenia, które mają do czynienia z przestrzeganiem komponent-model.
2. AFAIK JSF obsługuje tylko POST, więc jeśli chcesz dostać gdzieś masz aby zrobić zwykły servlet/JSP.
3. większość komponentów stara się dostarczać abstrakcji nad domenami, takimi jak relacyjne bazy danych i front-end JavaScript, a wiele razy te abstrakcje są "nieszczelne" i bardzo trudne do debugowania.
4. te abstrakcje może to być dobry punkt wyjścia dla młodszego programisty lub kogoś, kto nie czuje się komfortowo w danej domenie (np. front-end JavaScript), ale jest bardzo trudny do zoptymalizowania pod kątem wydajności, ponieważ jest kilka warstw zaangażowanych, a większość ludzi, którzy z nich korzystają, nie ma zielonego pojęcia o tym, co dzieje się pod maską.
5. mechanizmy szablonów, które są zwykle używane w JSF, nie mają nic wspólnego z działaniem projektorów internetowych. Edytory WYSIWYG dla JSF są prymitywne i w każdym razie twoje projektant da ci HTML / CSS, który będziesz musiał poświęcić wieki na konwersję.
6. rzeczy takie jak wyrażenia EL nie są sprawdzane statycznie i zarówno kompilator, jak i IDE nie robią dobrej roboty w znajdowaniu błędów, więc skończysz z błędami, które będziesz musiał złapać w czasie wykonywania. Może to być dobre dla dynamicznie wpisywanych języków, takich jak Ruby lub PHP, ale jeśli muszę wytrzymać zwykły nadmiar ekosystemu Javy, wymagam pisania dla moich szablonów.

Podsumowując: czas zaoszczędzisz z JSF, od unikania pisania kodu JSP/servlet / bean boilerplate, wydasz go x10, aby go skalował i robił dokładnie to, co chcesz.

Dla mnie największą wadą JSF 2.0 jest krzywa uczenia się nie tylko JSF, ale także bibliotek komponentów, których musisz używać, aby wykonać użyteczną pracę. Rozważ oszałamiającą liczbę specyfikacji i standardów, z którymi masz do czynienia, aby naprawdę być biegłym: {]}

• HTML w różnych wcieleniach. Nie udawaj, że nie musisz o tym wiedzieć.
• HTTP -- gdy nie wiesz o co chodzi musisz otworzyć Firebug i zobaczyć. W tym celu musisz wiedzieć to.
• CSS -- czy ci się to podoba czy nie. Nie jest tak źle, a przynajmniej jest kilka fajnych narzędzi.
• XML -- JSF będzie prawdopodobnie pierwszym miejscem, w którym użyjesz przestrzeni nazw do tego stopnia.
• Specyfikacja Serwletu. Prędzej czy później przejdziesz do wywoływania metod w tym pakiecie. Poza tym musisz wiedzieć, jak twoja twarz zmienia się w XHTML czy cokolwiek innego.
• JSP (głównie dlatego, że wiesz dlaczego nie potrzebujesz go w JSF)
• JSTL (znowu, głównie po to, aby poradzić sobie z legacy framework)
• język wyrażeń (EL) w jego różnych formach.
• ECMAScript, JavaScript, czy jak tam chcesz to nazwać.
JSON-powinieneś to wiedzieć, nawet jeśli go nie używasz.
• AJAX. Powiedziałbym, że JSF 2.0 robi przyzwoitą robotę ukrywając to przed tobą, ale nadal musisz wiedzieć, co się dzieje.
• DOM. I jak korzysta z niej przeglądarka. Zobacz ECMAScript.
• DOM Events -- temat sam w sobie.
• Java Persistence Architecture (JPA) oznacza to, że chcesz, aby Twoja aplikacja miała bazę danych zaplecza.
• sama Java.
/ Align = "left" /
• Context Dependency Injection specification (CDI) i jak koliduje z i jest używana z JSF 2.0
• JQuery -- chciałbym zobaczyć, jak sobie radzisz bez tego.

Teraz, kiedy skończysz z tym, możesz przejść do zastrzeżonych specyfikacji, a mianowicie bibliotek komponentów i bibliotek dostawców, które będziesz zbierać wzdłuż sposób:

• PrimeFaces (Moja biblioteka komponentów do wyboru)
• RichFaces
• MyFaces
• ICEFaces
EclipseLink (Mój dostawca JPA)
• Hibernate
• Spoina

I nie zapomnij o pojemniku! I wszystkie te pliki konfiguracyjne:

• GlassFish (2, 3 itd.)
• JBoss
• Tomcat

Więc ... to ułatwia sprawę? Oczywiście, JSF 2.0 jest "łatwy" tak długo, jak wszystko, co chcesz zrobić, to najbardziej podstawowe strony internetowe z najprostsze interakcje.

Mówiąc najprościej, JSF 2.0 jest najbardziej skomplikowaną i uciążliwą mieszanką technologii sklejonych, jaka istnieje obecnie we wszechświecie oprogramowania. I nie mogę wymyślić niczego, co wolałabym użyć.

1. Niedoświadczeni Programiści zazwyczaj tworzą aplikacje, które są boleśnie wolne, a kod będzie naprawdę brzydki i trudny do utrzymania. Jego zwodniczo prosty początek, ale w rzeczywistości wymaga trochę inwestycji w naukę, jeśli chcesz pisać dobre programy.
2. przynajmniej na początku często "utkniesz" na jakimś problemie i będziesz spędzał więcej czasu czytając posty balusc w Internecie niż faktycznie pracując:) po jakimś czasie będzie tego coraz mniej, ale i tak może być irytujące.
3. jeszcze bardziej irytujące, gdy dowiadujesz się, że problem nie wynika z braku wiedzy/błędu, ale rzeczywiście błąd. Mojarra była (is?) dość buggy, a kolejna warstwa komponentów dodaje jeszcze więcej problemów. Richfaces był największym gównianym oprogramowaniem, jakie kiedykolwiek napisano :) Nie wiem jak to jest teraz w wersji 4. Mamy Primefaces, który jest lepszy, ale nadal napotkasz błędy lub brak funkcji, szczególnie w przypadku bardziej egzotycznych komponentów. A teraz będziesz musiał zapłacić za Primefaces aktualizacje. Więc powiedziałbym, że jego buggy, ale jego coraz lepiej, zwłaszcza po wersji 2.2, Naprawiono pewne problemy ze specyfikacją. Framework coraz dojrzalszy, ale wciąż daleki od ideału (może myfaces lepszy?).
Nie uważam go za szczególnie elastyczny. Często, jeśli potrzebujesz czegoś bardzo bardzo dostosowanego i nie ma żadnych komponentów, które to robią-będzie to trochę bolesne. Ponownie mówię z perspektywy przeciętnego dewelopera - tego z terminami, samouczkami szybkiego czytania i wyszukiwaniem stackoverflow kiedy utkniesz, ponieważ nie ma czasu, aby dowiedzieć się, jak to naprawdę działa :) często niektóre komponenty wydają się mieć "prawie" to, czego potrzebujesz, ale nie dokładnie i czasami możesz spędzić zbyt dużo czasu, aby zrobić coś, co chcesz :) trzeba być ostrożnym w ocenie, czy lepiej jest stworzyć własny lub torturować istniejący komponent. Właściwie, jeśli tworzysz coś naprawdę wyjątkowego, nie polecam JSF.

Więc w skrócie moje wady to: złożoność, niezbyt płynny rozwój postęp, buggy, nieelastyczny.

Oczywiście są też zalety, ale nie o to pytałeś. W każdym razie to moje doświadczenie z frameworkiem inni mogą mieć różne opinie, więc najlepszym sposobem jest po prostu spróbować go przez chwilę, aby zobaczyć, czy to dla ciebie (po prostu coś bardziej złożonego - nie naiwne przykłady - JSF naprawdę świeci tam:) IMHO najlepszym przypadkiem użycia JSF są aplikacje biznesowe, takie jak CRMs itp...

"JSF wyświetli HTML i JavaScript z warstwą widoku, których nie można kontrolować ani zmieniać bez wchodzenia w kod kontrolera."

W rzeczywistości JSF daje Ci elastyczność, możesz użyć standardowych / zewnętrznych komponentów lub stworzyć własne, które masz pełną kontrolę nad tym, co jest renderowane. Jest to tylko jeden xhtml, którego potrzebujesz, aby stworzyć własne komponenty za pomocą JSF 2.0.

Opracowaliśmy przykładowy projekt z JSF (to były trzytygodniowe badania, więc możemy stracić kilka rzeczy!)

Staramy się używać core jsf, jeśli komponent jest potrzebny, używamy PrimeFaces.

Projekt był stroną internetową z nawigacją. Każda strona powinna być ładowana przez ajax po kliknięciu menu.

Strona ma dwa zastosowania:

1. strona z siatką. Siatka jest ładowana przez ajax i powinna obsługiwać sortowanie i stronicowanie
2. trzyetapowa strona kreatora. Każda strona ma Walidacja po stronie klienta (dla prostych walidacji) i po stronie serwera Walidacja bazowa ajax (dla złożonych walidacji). Każdy wyjątek serwera (z warstwy usług) powinien być wyświetlany na tej samej stronie kreatora bez przechodzenia do następnej strony.

Stwierdziliśmy, że:

1. musisz użyć kilku hacków z omniFaces, aby poprawić stan widoku JSF. Stan JSF zostanie uszkodzony podczas dołączania stron za pomocą ajax do siebie. Wydaje się, że błąd w JSF i może zostać naprawiony w następnym wydania (Nie w 2.3).
2. JSF Flow nie dziala poprawnie z Ajaxem (lub nie moglismy go sprawdzic!) Staramy się użyć komponentu primeface wizard zamiast tego, ale Walidacja klienta wydaje się nie wspierana i średnia, podczas gdy nie był to standardowy standard przepływu JSF.
3. Kiedy używasz niektórych komponentów jQuery, takich jak jqGird, i musisz załadować wyniki JSON, zaleca się użycie czystego servleta, JSF nic nie zrobi dla Ciebie. Więc jeśli używasz tego rodzaju komponentów, Twój projekt nie będzie pasował w JSF.
4. próbujemy wykonać Skrypty klienckie, gdy ajax zakończy się przez {[0] } i okazało się, że PF 4 zaimplementował własne zdarzenia ajax. Mieliśmy kilka komponentów jQuery i musimy zmienić ich kod.

Jeśli zmienisz powyższą próbkę na non Ajax projekt ( lub przynajmniej mniej ajax projektu) nie napotkasz wiele powyższych problemów.

JSF nie działa dobrze w pełni ajax base strona internetowa.

Oczywiście w JSF znajdziemy wiele fajnych funkcji, które mogą być bardzo pomocne w niektórych projektach, więc rozważ swoje potrzeby projektowe.

Proszę zapoznać się z dokumentami technicznymi JSF, aby przejrzeć zalety JSF, a moim zdaniem największą zaletą JSF jest pełne i ogromne wsparcie od @ BalusC; -)

Nie jestem w ogóle ekspertem od serwerów Java. Ale IMHO główną wadą jest to, że jest po stronie serwera. Jestem zmęczony uczeniem się i używaniem frameworków web presentation layer po stronie serwera, takich jak ASP.NET formularze internetowe, ASP.NET MVC, Java Server, Struts, frameworki php oraz frameworki ruby on rails. Pożegnałem się z nimi wszystkimi i przywitałem się z Angularjs i maszynopisem. Moja warstwa prezentacji działa w przeglądarce. Nie ma znaczenia czy jest obsługiwany przez Windows IIS z php czy ASP.NET, lub jeśli jest obsługiwany przez serwer WWW Apache działający na Linuksie. Muszę tylko nauczyć się jednego frameworka, który działa wszędzie.

Tylko moje dwa centy.

Dla mnie największym mankamentem JSF jest słaba obsługa stron generowanych programowo (dynamicznie).
Jeśli chcesz dynamicznie konstruować swoją stronę (Utwórz model komponentu strony) z kodu java. Na przykład, jeśli pracujesz nad WYSIWYG Web page constructor. Odpowiednia dokumentacja tego przypadku użycia nie jest ogólnie dostępna. Istnieje wiele punktów, w których trzeba eksperymentować i rozwój jest cichy powolny. Wiele rzeczy po prostu nie działa tak, jak można się spodziewać. Ale generalnie jego możliwe, że jakoś to zhakujesz.
Dobrze, że to nie problem w filozofii czy architekturze JSF. To po prostu za mało rozbudowane (o ile mi wiadomo).

JSF 2 przyniósł Komponenty kompozytowe, które powinny ułatwić rozwój komponentów, ale ich wsparcie dla dynamicznej (programowej) konstrukcji jest bardzo słabe. Jeśli pokonasz cichy skomplikowany i prawie nieudokumentowany proces dynamicznej konstrukcji komponentu kompozytowego, przekonasz się, że jeśli zagnieżdżasz kilka komponentów kompozytowych trochę głębiej, przestają pracować, rzucając pewne wyjątki.

Ale wydaje się, że społeczność JSF jest świadoma tych niedociągnięć. Pracują nad tym, jak widać z tych dwóch bugs
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599{[9]

Sytuacja powinna być lepsza z JSF 2.2 przynajmniej jeśli mówimy o specyfikacji.

Komentuję moje ostatnie miesiące doświadczenia w Primefaces/JSF:

• Jeśli możesz używać komponentów "z półki", to chyba nie jest to straszne.
• jednak nie gra dobrze, gdy tylko wyjdziesz na zewnątrz i potrzebujesz niestandardowego interfejsu użytkownika. - Na przykład, musieliśmy użyć Bootstrap Twittera dla naszego projektu. (Nie primefaces bootstrap).
  • teraz nasze strony działają w następujący sposób:
    • ładowanie strony.
    • użytkownik wchodzi w interakcję z Primefaces, który ma funkcjonalność ajax
    • Bootstrap ' s javascript bindings break
    • uruchamiamy dodatkowy javascript, aby zrebindować wszystko

Obietnica JSF, aby uniknąć pisania javascript zamieniła się w pisanie więcej javascript niż byśmy mieli, gdyby nie używać Primefaces--i że javascript to jest naprawić, co primefaces łamie.

To zlew czasu -- chyba że znowu użyjesz" z półki " rzeczy. Również bardzo brzydki (Primefaces), gdy trzeba pracować z selenem. Wszystko da się zrobić ... ale jeszcze raz ... zostało tylko tyle czasu.

Zdecydowanie unikaj tego, jeśli pracujesz z zespołem UX/design i potrzebujesz szybko iterować NA UI-możesz zaoszczędzić czas, ucząc się jquery / pisania prostego HTML-lub patrząc na react / angular.

JSF ma wiele zalet, pytanie jest na niekorzyść dodam kilka punktów na ten temat.

Na praktyczny scenariusz realizacji projektu www z w ramach czasowych trzeba mieć oko na następujące czynniki.

• Czy masz wystarczająco dużo starszych członków w swoim zespole, którzy mogą zasugerować najlepsze kontrolki odpowiednie dla każdego scenariusza?

• Czy masz przepustowość, aby dostosować się do początkowej krzywej uczenia się?

• Czy masz wystarczającą wiedzę w swojej zespół, który może przejrzeć JSF
  rzeczy produkowane przez deweloperów?

Jeśli Twoja odpowiedź brzmi " nie " na pytania, możesz skończyć w bazie kodowej, która nie jest możliwa do utrzymania.

JSF ma tylko jedną wadę: przed rozpoczęciem tworzenia" JSF " powinieneś wyraźnie zrozumieć tworzenie stron internetowych, rdzeń Javy i architekturę front-end.

Obecnie "nowe" frameworki JavaScript po prostu spróbuj skopiować / wkleić model oparty na komponentach "JSF".

Wśród wszystkich" mainstreamowych " frameworków, takich jak Spring MVC, Wicket, Gobestry itp., JSF Java EE z jego komponentami kompozytowymi jest najbardziej rozbudowaną technologią warstwy prezentacyjnej i zorientowaną na komponenty. Jest nieco kłopotliwa i niekompletna w porównaniu z rozwiązaniami dostarczonymi przez HybridJava.