Gründe, JSF NICHT zu verwenden [closed]

64

Ich bin neu bei StackExchange, aber ich habe mir gedacht, dass Sie mir helfen können.

Wir erstellen eine neue Java Enterprise-Anwendung und ersetzen eine ältere JSP-Lösung. Aufgrund vieler Änderungen werden die Benutzeroberfläche und Teile der Geschäftslogik komplett überarbeitet und neu implementiert.

Unser erster Gedanke war JSF, wie es der Standard in Java EE ist. Anfangs hatte ich einen guten Eindruck. Aber jetzt versuche ich, einen funktionalen Prototyp zu implementieren, und habe einige ernsthafte Bedenken, ihn zu verwenden.

Zuallererst erzeugt es den schlimmsten, überladensten ungültigen Pseudo-HTML / CSS / JS-Mix, den ich je gesehen habe. Es verstößt gegen jede einzelne Regel, die ich in der Webentwicklung gelernt habe. Darüber hinaus wirft es zusammen, was noch nie so eng miteinander verbunden sein sollte: Layout, Design, Logik und Kommunikation mit dem Server. Ich verstehe nicht, wie ich diese Ausgabe komfortabel erweitern kann, ob mit CSS gestylt, UI-Bonbons hinzugefügt (wie konfigurierbare Hotkeys, Drag-and-Drop-Widgets) oder was auch immer.

Zweitens ist es viel zu kompliziert. Die Komplexität ist hervorragend. Wenn Sie mich fragen, ist es eine schlechte Abstraktion grundlegender Webtechnologien, die am Ende verkrüppelt und nutzlos ist. Welche Vorteile habe ich? Keine, wenn Sie darüber nachdenken. Hunderte von Bauteilen? Ich sehe zusätzlich Zehntausende von HTML / CSS-Snippets, Zehntausende von JavaScript-Snippets und Tausende von jQuery-Plug-Ins. Es löst wirklich viele Probleme - wir hätten es nicht, wenn wir JSF nicht verwenden würden. Oder das Front-Controller-Pattern überhaupt.

Und schließlich denke ich, dass wir in zwei Jahren von vorne anfangen müssen. Ich verstehe nicht, wie ich unser erstes GUI-Modell implementieren kann (außerdem haben wir keinen JSF-Experten in unserem Team). Vielleicht könnten wir es irgendwie zusammen hacken. Und dann wird es noch mehr geben. Ich bin sicher, wir könnten unseren Hack hacken. Aber irgendwann werden wir stecken bleiben. Aufgrund von allem, was darüber liegt, hat die Serviceebene die Kontrolle über JSF. Und wir müssen von vorne anfangen.

Mein Vorschlag wäre, eine REST-API mit JAX-RS zu implementieren. Erstellen Sie dann einen HTML5 / Javascript-Client mit clientseitigem MVC. (oder etwas Geschmack von MVC ..) Übrigens; Wir werden die REST-API sowieso brauchen, da wir auch ein teilweises Android-Frontend entwickeln.

Ich bezweifle, dass JSF heutzutage die beste Lösung ist. Da sich das Internet weiterentwickelt, verstehe ich wirklich nicht, warum wir diesen "Rechen" verwenden sollten.

Was sind nun die Vor- und Nachteile? Wie kann ich betonen, dass ich JSF nicht verwenden soll? Was sind die Stärken von JSF gegenüber meinem Vorschlag?

— Bruno Schäpper
quelle

24

Das ist eine gut geschriebene Frage eines neuen Benutzers. Hinterlassen Sie beim Abstimmen einen Kommentar.

— ThiefMaster

2

Da Sie alles neu schreiben, würde ich nicht nur in Betracht ziehen, JSF nicht zu verwenden, sondern Java überhaupt nicht zu verwenden. Moderne Skriptsprachen (dh nicht PHP oder Perl) sind ziemlich nett und entwicklerfreundlich.

— ThiefMaster

11

Ich habe nicht abgelehnt, aber das ist keine Frage, es ist eine Schande. Vain hat sich entschieden, dass er JSF hasst, jetzt fragt er aus mehr Gründen, es nicht zu benutzen?

— Michael Borgwardt

4

Java ist die beste Wahl, wenn Ihre Anwendung groß (komplex und / oder skalierbar) und / oder verteilt sein soll und viele Dienste verwendet. Wenn Ihre Anwendung nicht in diese Kategorie passt (nicht so komplex ist und nicht skalierbar sein muss), sind Python (Django) oder Ruby (Rails) die bessere Wahl. Die Komplexität von JSF hat die Vorteile der Leistung, mit der es kommt; Als Alternative sollten Sie sich andere Web-Frameworks wie Spring MVC oder Struts 2 ansehen, wenn Java obligatorisch ist.

— m3th0dman

14

Dies ist ein Problem, das nach Backups sucht, keine Frage an sich.

26

Es gibt mindestens einen sehr guten Grund, über JSF nachzudenken.

Es ist ein Standardbestandteil des Java EE-Stacks und wird daher für sehr, sehr lange Zeit in ALLEN Java EE-Containern verfügbar sein - und funktionieren . Und auch gepflegt, ohne dass Sie dies tun müssen, wenn Sie sich strikt an die Java EE-Spezifikation halten.

Wenn dies ein Problem für Sie ist, sollten Sie darüber nachdenken. Die meiste Software lebt länger als ihre Designer denken, besonders wenn dies beim Schreiben berücksichtigt wird.

4

Da bin ich mir nicht sicher. Für J2EE sind die Wörter "Standard" und "Working" nicht in Stein gemeißelt, insbesondere wenn es sich um ein System handelt, das viele Jahre lang unterstützt wird / werden sollte, einschließlich Änderungen an der verwendeten Version von j2ee.

— Magallanes

7

Nach meiner (eingeschränkten) Erfahrung mit JSF trifft dieses Argument eigentlich nicht zu. Ich habe Anwendungen gesehen, die mit einer Version von JSF und keinem vernünftigen Migrationspfad zu einer neueren Version hängen geblieben sind. Sicher, der App-Server hat es immer noch ausgeführt, aber das war ungefähr die gesamte Unterstützung, die Sie erhalten würden, wenn Sie nicht viel Geld für überteuerte Support-Verträge hätten.

— Jens Schauder

@JensSchauder Meine Erfahrung ist nur, dass Sie portable Anwendungen schreiben, migrieren und deren Version von jsf aktualisieren können. Dies beinhaltet, die Spezifikation zu kennen und sie zu codieren, nicht ihre Implementierung. Es funktioniert, da das Codieren von JPA anstelle von Ruhezustand funktioniert. Das mache ich schon seit Jahren.

— ymajoros

14

Was sind nun die Vor- und Nachteile? Wie kann ich betonen, dass ich JSF nicht verwenden soll? Was sind die Stärken von JSF gegenüber meinem Vorschlag?

Sie scheinen sich bereits über die Nachteile geeinigt zu haben, und ich muss einigen davon zustimmen (es trennt Layout und Logik nicht genug, und das resultierende HTML ist oft grausam), aber anderen widersprechen (wenn Sie es verwenden) Facelets, die ich sehr empfehlen würde, dann sollte die Ausgabe definitiv gültig sein).

Also hier sind einige Profis:

Es gibt einige sehr leistungsfähige Komponentenbibliotheken wie PrimceFaces oder RichFaces, die viele sofort einsatzbereite Funktionen bieten. Diese können Ihnen viel Arbeit ersparen, wenn sie Ihre Anforderungen abdecken (weniger, wenn Sie nicht verhandelbare Anforderungen haben, die nicht von ihnen abgedeckt werden).
Composite Components bieten eine sehr übersichtliche Möglichkeit, Ihre Seiten zu modularisieren
JSF lässt sich sehr gut in den Rest von Java EE integrieren
AJAX via Component Re-Rendering ist wirklich einfach und bequem

Keiner dieser Vorteile ist jedoch so groß, dass Sie JSF gegenüber einem anderen Framework verwenden sollten, mit dem Ihr Team bereits Erfahrung hat.

— Michael Borgwardt
quelle

1

Es sind nicht die IDs, es sind ungültige Attribute. Wie "Rolle" und "Arie-erweitert" in der Tab-Ansicht. Wissen Sie, wie Sie das beheben können?

— Bruno Schäpper

1

@Vain: Nö, scheint ein anderes Problem zu sein, vielleicht mit einer Komponente, die ich nicht benutzt habe oder die neu ist. Es ist möglich, die HTML-Ausgabe von JSF-Komponenten zu ändern, indem Sie einen alternativen Renderer angeben (der im Idealfall nur eine oder zwei Methoden des Standard-Renderers überschreibt). Natürlich sollten Sie dies nicht tun, um nur gültige Markups zu erhalten.

— Michael Borgwardt

1

Das grausame HTML ist auf die verwendete Implementierung zurückzuführen. Nach meinem Verständnis ist der Debug-Modus der Referenz-JSF-Implementierung hier besonders schlecht. Würdest du bessere Einstellungen kennen, um besseres HTML zu produzieren?

1

@ Thorbjørn Ravn Andersen Ja, das Problem mit ungültigem HTML ist eigentlich ein Problem von PrimeFaces. Wir verwenden es, weil es auf der jQuery-UI aufbaut. Wie lautet dein Rat; soll ich eine andere bibliothek benutzen Ich mag wirklich gültiges HTML. Für mich ist es einfach ein MUSS.

— Bruno Schäpper

1

Wenn ich meine erste Frage hier noch einmal betrachte, möchte ich einige Erfahrungen über Ihre Profis mitteilen: Wir arbeiten mit JSF zusammen, und mit diesen Erfahrungen würden wir es nicht noch einmal auswählen. Kaum etwas funktioniert wie erwartet und ist sofort einsatzbereit. Ja, es gibt mächtige Bibliotheken. Am Ende haben wir jedoch alle unsere Komponenten selbst hergestellt, da sie nicht so funktionieren würden, wie wir es brauchten. Es ist erstaunlich, wie schnell wir unseren eigenen "DataTable" hatten, der beim Scrollen nur schleppend geladen wurde. Composite Components haben bei uns nicht funktioniert, ich kann Ihnen nicht sagen warum, sie sind vermutlich fehlerhaft. Das erneute Rendern von AJAX bereitet dem clientseitigen JS tatsächlich Schmerzen.

— Bruno Schäpper

9

JSF ist ein angemessenes Stateful-Web-Framework für Java, das ein Standard ist. Dies bedeutet, dass es von vielen großen Anbietern (einschließlich FOSS) sofort unterstützt wird. Es unterstützt Bibliotheken von Drittanbietern (PrimeFaces, IceFaces usw.). Es bricht jedoch im Grunde genommen das Web aufgrund seiner staatlichen Natur (und einer Reihe anderer Dinge). Siehe Matt Raibles Vergleich von JVM-basierten Web-Frameworks .

Bearbeiten - mit JSF 2.2 - können Sie anfangen zu argumentieren, dass es das Web nicht mehr so stark beschädigt wie früher. Tatsächlich ist die HTML5-Integration nicht schrecklich :-).

— Martijn Verburg
quelle

1

Es ist in der Tat "das Netz ist kaputt". Und danke für Matt Raibles Vergleich, der das nicht wusste.

— Bruno Schäpper

3

Beachten Sie, dass JSF nicht unbedingt statusbehaftet ist. Ich bin damit einverstanden, dass dies häufig der Fall ist, aber es gibt eine gute Unterstützung für zustandslose GET-basierte Anfragen. Wenn Sie kein Formular verwenden, gibt es überhaupt keinen Status.

— Arjan Tijms

Fair point Arjan, ich denke, ich habe gerade zu vielen staatlichen Verwendungen gesehen.

— Martijn Verburg

Link zu Raibles

— zaidaus 10.06.13

6

Wir hatten eine ältere JSP / Struts 1.0-Anwendung. Wir haben Struts 2, JSF und alles andere, was seit Struts 1 passiert ist, übersprungen und sind zu Spring 3.0 gesprungen. Es hat Unterstützung (und eine aktive Community) für unsere Wunschliste - Eclipse IDE, MVC und REST. Außerdem haben wir unser altes, selbst entwickeltes Javascript / Ajax für jquery aufgegeben.

YMMV, aber der Frühling war für uns eine reibungslose Migration.

— jqa
quelle