Ich weiß, dass es hier viele Fragen gibt, die einen Rahmen mit einem anderen vergleichen. Ich glaube, ich muss noch eins hinzufügen.
Was ist der Vorteil von play framework gegenüber Tapestry5 framework? Welchen würdest du empfehlen und warum?
Hier sind die Ähnlichkeiten, die ich gefunden habe.
Warum sollte man eins vor dem anderen wählen? Ich habe beide benutzt, um eine "verherrlichte Hallo Welt" Art von Anwendungen zu machen und ich habe das Gefühl, dass beide sehr ähnlich sind.
Ich habe keine direkten Erfahrungen mit Tapestry. Aber ein Kollege in einem Projekt, in dem wir Play verwenden, hat damit gearbeitet, und er hatte es wirklich satt. Er hatte viele Beschwerden, aber Sie finden die meisten von ihnen aufgeführt hier *.
Ich persönlich denke, die Hauptvergleichspunkte zwischen Play und anderen Frameworks sind:
Wenn Ihr Framework dies alles unterstützt, können Sie auch tiefer ins Detail gehen, etwa wenn es sich um einen zustandslosen / statusbehafteten Rahmen handelt usw.
* Wayback-Version des Rechners, da der Post aus dem Stack-Überlauf gelöscht wurde.
Beachten Sie auch, dass Play nicht (direkt?) mit Standardanwendungsservern kompatibel zu sein scheint; Es verwendet nicht die Servlet-API, sondern eigene Definitionen von Request und Reponse.
Es ist auch ziemlich drakonisch, Java-Klassen bei jeder Anfrage erneut zu kompilieren / neu zu laden (Entschuldigung, wenn dies FUD ist, erinnere ich mich an das JavaOne-Gespräch).
Es ist nicht komponentenbasiert, es ist ein aktionsbasiertes Framework wie Struts oder SpringMVC; Es verwendet Vorlagen, die eine Verbesserung gegenüber JSPs darstellen, denen jedoch der vollzyklusbasierte Ansatz von Tapestry fehlt. Ein Großteil der Kraft von Tapestry kommt durch den Aufbau komplexer Funktionen aus einfachen Elementen.
Tapestry enthält eine hochentwickelte Technologie für den Umgang mit Assets (Bilder, Stylesheets, JavaScript-Bibliotheken), die in JARs gepackt sind. Es ist alles für den Benutzer und den Entwickler transparent, lassen Sie einfach die JARs auf dem Klassenpfad und sie automatisch laden und konfigurieren.
Ich denke, Spiel! hat einige gute Ideen und einen sehr guten Namen, aber spielt in einer anderen Liga als Tapestry. Es ist ziemlich drakonisch, einen Server-seitigen Zustand zu vermeiden ... im Gegensatz dazu verwendet Tapestry begrenzte Mengen an serverseitigem Zustand und verwaltet diesen Zustand sorgfältig, und zwar weitgehend um eine Redirect-nach-Post-Semantik.
Es gibt nur so weit, dass Sie in einen aktionsorientierten Rahmen gehen können, wenn Sie dieselben Verhaltensweisen haben, die viele verschiedene Seiten umfassen. Obwohl ich Tapestry selbst auf einer Einzelseitenanwendung verwenden würde, ist es wahr, dass Tapestry bei der Entwicklung größerer Apps mit größeren Teams wirklich glänzt.
Das Play-Framework ist nicht komponentenbasiert. Es gibt keine Java-Klasse, die jede Seite unterstützt. Stattdessen folgt eine strenge MVC-Trennung, bei der das Fleisch der Anwendung direkt im Modell liegen muss.
Play soll Ruby on Rails oder Grails sehr ähnlich sein, aber in Java. Außerdem ist es möglich, eine Play-Anwendung auf einem eigenen integrierten Server (basierend auf JBoss Netty) zu implementieren.
Welches Sie auswählen, hängt hauptsächlich davon ab, wie Sie sich der Ansichtsebene nähern. Wenn Sie plain HTML, CSS und JavaScript bevorzugen, gehen Sie mit Play! Wenn Sie Java-Komponenten bevorzugen, verwenden Sie Tapestry.
Ich weiß überhaupt nicht spielen, ich habe nur 5 Minuten Einführungen gesehen, aber es hat mir nicht gefallen, aber ich habe etwas Erfahrung mit Tapestry 5. Was sind Vorteile:
BTW Tapisserie 5 im Action Book wurde gerade auf MEAP verfügbar
Bitte beachten Sie nochmals, dass ich keine Ahnung von Spielen habe und nur versucht habe, auf die von Ihnen erwähnten Punkte einzugehen. Wenn Sie mehr Vorteile von Tapestry (nicht überspielen, aber insgesamt starke Seiten des Frameworks) wünschen, schreiben Sie mir bitte. Ich werde glücklich sein, mehr zu schreiben (besonders, weil ich im Begriff bin, Kunden davon zu überzeugen, von Frühling zu T5 zu wechseln, und jede Übung vor diesem Gespräch ist willkommen;))
Grüße Michał
Die Vorteile des Spiels! Framework vs Tapestry5 sind:
Es gibt auch Module von Drittanbietern für Tapestry5 - aber sie sparen Ihnen nicht Zeit, sie werden Zeit verbrauchen. Die meisten von ihnen sind nicht gepflegt und Sie müssen immer alle 3rd-Party-Code zu verzweigen, zu verstehen und zu ändern, damit es mit den neuesten Tapestry-Versionen funktioniert. Am Ende ist es einfacher, alles selbst zu schreiben. Im Allgemeinen ist Tapestry5 teurer, da Sie die Codepflege berechnen müssen. Bei jedem Tapestry-Upgrade müssen Sie Ihren Code ändern, da Methoden veraltet sind - nicht nur in Ihrem eigenen Code, sondern auch in allen anderen Modulen von Drittanbietern, die Sie integriert haben. Dies ist ein großer Zeitmörder und kostet eine Menge Geld.
Im Vergleich zu Play! wo man einfach etwas wie Facebook / oAuth-Authentifizierung greifen kann und es einfach funktioniert - auch in den nächsten Updates des Frameworks ist das ein riesiger Kostenvorteil.
Generell bin ich immer der Meinung, dass Java-Webapps am teuersten zu entwickeln, zu warten und zu hosten sind. Mit Play! Wird die Berechnung jedoch besser - obwohl der Ansatz manchmal weniger "intelligent" ist. Aber wenn Time-to-Market und Entwicklungskosten zählen, gehen Sie für Play! oder eine andere Technologie wie RubyonRails oder PHP. RubyonRails-Entwickler sind jedoch so teuer wie Java-Leute.
Ich würde auch sagen, auch für Play- und Tapestry-Nutzer ist es offensichtlich, dass Tapestry konventioneller als Play ist und einfachere Standards erfüllt. Ich würde nicht behaupten, dass das gut oder schlecht ist Wieder einmal ist es nicht oft eine schlechte Sache, irgendwo abseits der ausgetretenen Pfade zu gehen. Spielen Sie ein wirklich gut eingebautes, hausgemachtes Zeug. Sie brauchen also nicht so viel zusätzliche Module oder Plug-Play zu anderen Libraries.
Beide haben großartige eingebaute Funktionen: Echtzeit-Nachladen von Live-Inhalten, das ist unglaublich, Injektion, ... Manchmal hat man eine bessere Unterstützung als die andere (zum Beispiel REST for Play). Sie beide verbessern wirklich die Produktivität. Aber Tapestry ist dem Standard etwas näher als Play .
Sie müssen keine REST-Unterstützung in Play einfügen, weder eine Servlet-Engine verwenden noch ein Build-System anschließen. Es ist ein ALL-INCLUSIVE-Angebot :). Aber wenn Sie im professionellen Kontext Standards erfüllen müssen, ist das viel schwieriger.
Ich musste mich vor kurzem zweimal entscheiden.
Das ist also aus meiner Sicht einer der Hauptunterschiede zwischen diesen beiden unglaublichen Frameworks.
Matt Raible (auch wenn kontrovers diskutiert;)) sagte , dass Sie nicht Framework wählen sollten, was das tun kann, aber in Bezug auf auf was sie nicht können! Es ist eindeutig die Hauptdebatte hier! Die können beide großartige Arbeiten machen, aber auf zwei leicht unterschiedliche Arten:)
Tags und Links playframework tapestry