Ich habe einige Erfahrungen zu diesem Thema gesammelt, als ich im November begann, ein neues Projekt zu programmieren. Das Projekt befindet sich in einem späten Stadium.
Für mich sind die folgenden Design-Richtlinien waren wichtig:
- eine moderne Technologie-Stack verwenden, die sowohl Spaß zu verwenden und wird im allgemeinen Gebrauch in Zukunft sein.
- Reduzieren Sie die Anzahl der Projektartefakte - verwenden Sie Anmerkungen/Java-Code, wo es sinnvoll ist, verzichten Sie auf XML.
- Verwenden Frameworks, die Open-Source-
- sind, haben eine aktive Community
- nicht Alpha-Stadium
- leicht sind
- Vervielfältigung von Konzepten darin, die Konzepte zu meinen beiden Kolleginnen erklären kann ich
- vermeiden Entwickler, die - obwohl sie gute Programmierer sind - niemals dependency injection (DI) oder Webframeworks verwendet haben.
- Kann als techological Grundlage für zukünftige Projekte
Google Guice dienen als DI-Container eine offensichtliche Wahl waren - eindeutig die gut durchdachte DI Contianer, mit brillantem Entwickler und eine guten Gemeinschaft. Es erfüllt alle oben genannten Aufzählungspunkte.
Also habe ich meinen grundlegenden Technologie-Stack eingerichtet. Begann mit Guice, hinzugefügt Hibernate für Persistenz (zusammen mit warp-persist und warp-servlet). Dann schrieb ich einige grundlegende DAO, die etwas auswählt.
Dann habe ich versucht, folgendes zu tun: fügte ein anderes Web-Framework hinzu.
habe ich eine einfache Seite mit einer Tabelle, von der DAO bevölkert, Kopf- und einem Textfeld mit alle vier Rahmen.
Das waren meine Ergebnisse beim Vergleich der vier Gerüste.
XSLT und XStream ist eine Art Hardcore-Ansatz. Es ist nicht wirklich ein Framework, sondern eine brauchbare, völlig zustandslose Technologie für Hochleistungsanwendungen. Dies war bei weitem der schnellste Weg, die Testseite zu bedienen. Im Debug-Modus, 3 ms auf localhost im Vergleich zu etwa 30-50 ms mit den anderen framworks.
Guice Integration war relativ glatt und gut mit Warp-Servlet, die mir in Servlets injizieren und HTTPrequest, httpResponse, Sitzung in anderen Objekten injiziert, ohne sie herumzugeben. Nachteile: keine Community, da ich die einzige Person bin, die diesen Stack in Betracht zieht. - keine gebrauchsfertigen Komponenten.
Dann schaute ich auf JSF und Guice: es ist natürlich möglich, den Injektor in den Servlet-Kontext zu setzen und Guice als Service-Locator zu verwenden. Mit der einfachen Herangehensweise ist es unmöglich, Backbohnen irgendwo anders zu injizieren. Mit einem benutzerdefinierten Variable Resolver löst dies teilweise, aber dann verlieren Sie alle IDE Integration in Ihre JSF-Dateien und Sie müssen hässlich FQN für Ihre Backing-Beans verwenden, oder erstellen Sie eine Zeichenfolge-> Guice Key Mapping irgendwo. Beide sind hässlich wie:
- Vorteile: gute Community, viele Entwickler auf dem Arbeitsmarkt (keine Kriterien für mich). Sie werden nicht entlassen, wenn Sie JSF auswählen, wenn etwas schief geht.
- Nachteile: bringt seinen eigenen Inversion of control (IoC) Mechanismus, der konzeptuell mit guice kollidiert.
Warp-Widgets: Ich habe mein einfaches Beispiel mit diesem zum Spaß erstellt; Es ist ein frühes Alpha-Stadium. Es war schön zu verwenden und seine Komponenten sind einfach zu implementieren und wieder zu verwenden. Es zielt darauf ab, typsichere HTML mit perfekter Guice-Integration zu versehen. Da es damals aussah, als ob es nur einen aktiven Entwickler gäbe, der jetzt wahrscheinlich an Guice 2.0 arbeitet, würde ich sagen, dass die Community fast nicht existent ist. Es funktionierte wie ein Zauber, war einigermaßen schnell, aber ich wäre Alphatester gewesen. Das war einfach zu riskant, um es für ein kommerzielles Projekt zu betrachten.
Apache Wicket: dieses Projekt überraschte mich zuerst mit wicket-ioc und wicket-guice kommen im Kern-Download zusammen. Konstruktorinjektion in Webseiten ist nicht möglich, nur Setter + Feld. Die Injektion in Wicket-Webseiten ist einfach, fügen Sie einfach @Inject zu den Feldern hinzu, die Sie ausfüllen möchten - aber Sie sollten nicht verstehen, how it works in background. Tricky Zeug passiert. Das Einbetten von Webseiten ist theoretisch möglich - aber ich habe es nicht einmal verwendet, da dies die Verwendung von angehängten URLs unmöglich macht, und es wird mit dem persistierten/serialisierten Zustand vermischt. Eingespritzte Mitglieder von Klassen werden transparent mit der Webseitenserialisierung behandelt, die für die Aktivierung der Browser-Back-Unterstützung erforderlich ist. Wicket verwendet keine externen Artefakte - nur eine kleine Konfiguration von URLs in einer Anwendungsklasse. Die gesamte Konfiguration erfolgt also in Java - das passt gut zum Guice-Modell. Klare Trennung von HTML und Java. Es ist Open-Source wie die Mehrheit der Komponenten, die zahlreich und von guter Qualität sind. Es ist seit 2005 (?) Und ist ein Top-Level-Apache-Projekt. Obwohl es ein funktionsreicher Rahmen ist, ist sein API vernünftig kompakt (alle Kernklassen passen in einen einzigen JPEG auf meinem Bildschirm). Im Gegensatz zu anderen bringt es keinen eigenen IoC-Mechanismus mit, sondern denkt eher an IoC als eine Dienstleistung, die von Spring Framework, Guice, etc. zur Verfügung gestellt werden kann, und diese Philosophie macht es überlegen w.r.t. Guice Integration. Habe ich wirklich intelligente und einfache Ajax-Unterstützung erwähnt?
Frameworks nicht zu tief bewertet: tapestry5 - bringt seinen eigenen IoC. Seam: nicht ein Framework für sich, sondern ein Meta-Framework, das normalerweise Spring, JSF. Überwintern. (Obwohl Spring theoretisch durch Guice ersetzt werden könnte.)
Zusammenfassung: der bewerteten framworks, Apache Wicket war der klare Gewinner - in Bezug auf Guice Integration + alle anderen genannten Kriterien.
Neben uns zwei, einige andere Leute have had this problem before.
Liked Checkliste, aber ich denke nicht, Warp - *** macht Sinn. – Nachiket