it-swarm.com.de

Gründe, JSF NICHT zu verwenden

Ich bin neu bei StackExchange, aber ich dachte, Sie könnten mir helfen.

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

Unser erster Gedanke war JSF, da dies der Standard in Java EE) ist. Zuerst hatte ich einen guten Eindruck. Aber jetzt versuche ich, einen funktionalen Prototyp zu implementieren, und habe einige wirklich ernsthafte Bedenken es benutzen.

Erstens 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. Außerdem wirft es zusammen, was niemals so eng gekoppelt sein sollte: Layout, Design, Logik und Kommunikation mit dem Server. Ich sehe nicht ein, wie ich diese Ausgabe bequem erweitern könnte, sei es das Stylen mit CSS, das Hinzufügen von UI-Süßigkeiten (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, verkrüppelt und am Ende nutzlos. Welche Vorteile habe ich? Keine, wenn Sie darüber nachdenken. Hunderte von Komponenten? 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-Muster überhaupt.

Und zum Schluss denke ich, dass wir in etwa zwei Jahren von vorne anfangen müssen. Ich sehe nicht ein, wie ich all 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. Dann erstellen Sie einen HTML5/Javascript-Client mit clientseitiger MVC. (Oder einer Variante von MVC ..) Übrigens; wir wird sowieso die REST API) benötigen, da wir ein partielles Android Front-End auch entwickeln).

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

Was sind nun Vor-/Nachteile? Wie kann ich meinen Standpunkt betonen, JSF nicht zu verwenden? Was sind die Stärken von JSF gegenüber meinem Vorschlag?

64
Bruno Schäpper

Es gibt mindestens einen sehr guten Grund, JSF in Betracht zu ziehen.

Es ist ein Standardteil des Java EE-Stacks und wird daher in ALL Java EE-Containern) verfügbar sein - und funktioniert für eine sehr, sehr lange Zeit. Und auch gewartet, ohne dass Sie dies tun müssen, wenn Sie sich strikt an die Java EE-Spezifikation) gehalten haben.

Wenn dies ein Problem für Sie ist, sollten Sie es in Betracht ziehen. Die meisten Softwareprodukte leben länger als ihre Designer denken, insbesondere wenn sie beim Schreiben berücksichtigt werden.

26
user1249

Was sind nun Vor-/Nachteile? Wie kann ich meinen Standpunkt betonen, JSF nicht zu verwenden? Was sind die Stärken von JSF gegenüber meinem Vorschlag?

Sie scheinen sich bereits über die Nachteile entschieden zu haben, und ich bin mit einigen einverstanden (es trennt Layout und Logik nicht genug, und der resultierende HTML-Code ist oft grausam), aber bei anderen nicht einverstanden (wenn Sie ihn verwenden) Facelets, die ich sehr empfehlen würde, dann sollte die Ausgabe definitiv gültig sein).

Hier sind einige Profis:

  • Es gibt einige sehr leistungsstarke Komponentenbibliotheken wie PrimceFaces oder RichFaces, die sofort eine Vielzahl von Funktionen bieten. Diese können Ihnen viel Arbeit sparen, wenn sie Ihre Anforderungen abdecken (nicht so sehr, wenn Sie nicht verhandelbare Anforderungen haben, die nicht von ihnen abgedeckt werden).
  • Composite Components bieten eine sehr saubere Möglichkeit, Ihre Seiten zu modularisieren
  • JSF lässt sich sehr gut in den Rest von Java EE) integrieren
  • AJAX über das erneute Rendern von Komponenten ist wirklich einfach und bequem

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

14

JSF ist ein adäquates Stateful-Web-Framework für Java). Dies ist ein Standard, der von vielen großen Anbietern (einschließlich FOSS) sofort unterstützt wird. Es bietet eine starke Bibliotheksunterstützung von Drittanbietern (PrimeFaces, IceFaces) usw.) Allerdings bricht es das Web aufgrund seiner Stateful-Natur (und einer Reihe anderer Dinge) grundlegend. Siehe Matt Raibles Vergleich von JVM-basierten Web-Frameworks , JSF kommt normalerweise dem letzten nahe .

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

9
Martijn Verburg

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 selbstgemachtes Javascript/Ajax für jquery über Bord geworfen.

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

6
jqa