jede Erfahrung mit "Play" Java Web Development Framework?

Question

Ich habe gerade auf die folgenden neuen Java Web-Framework gestolpert: Spielen

http://www.playframework.org/

http://www.playframework.org/documentation/1.0/home

mit solch einer beeindruckenden Liste von Features, ich bin ziemlich überrascht, dass ich noch nicht gehört von es vor ...

Klingt wie die Java-Web-Entwicklung Land versprochen ...

jemand versucht hat? jede echte Erfahrung damit? Denkst du, es lohnt sich, es zu studieren?

Answer 1

Ich stimme Jason zu, dass Play einfach besser sein könnte als Grails. Mit vier Grails-Projekten (zwei Tapestry-Projekten und einem Wicket-Projekt vorangegangen) habe ich mich ernsthaft mit Play beschäftigt.

Eines der Dinge, die ich dachte, war cool über Grails ist, dass "alles groovy ist." Das heißt, Sie verwenden Groovy, um alles (außer HTML und CSS) zu schreiben - Domänen, Controller, Dienste, Seitenvorlagen (GSP), Tag-Bibliotheken, Hibernate API (GORM), Komponententests (GUnit) und Build-Skripte (GANT). Sie können sogar Shell-Skripte in Groovy schreiben. Es schien also eine längst überfällige Möglichkeit, alle Aspekte einer App in einer einzigen Sprache zu codieren - und damit auf die Zeit zurückzublicken, in der Desktop-Apps in einer Sprache wie C++ oder Delphi geschrieben wurden. Allerdings habe ich gelernt, dass eine Größe nicht alle hier passt.

Zum einen ist die IDE-Unterstützung für Groovy nicht großartig. IntelliJ macht den besten Job, aber da Groovy dynamisch ist, kann es nur so weit gehen. Die Refactoring-Tools fangen (nicht) alles ab, sodass Sie ihnen nicht 100% vertrauen können. Dies bedeutet, dass Sie besonders wachsam sein müssen mit Unit-Tests. Auch hier, weil Grails sich so sehr auf dynamische "Magie" verlässt, die zur Laufzeit passiert, muss sich das Unit-Testing in Grails auf eine ausgedehnte Spottschicht stützen, um es zu emulieren, und diese spottende Ebene ist eigenartig. Ein drittes Problem ist, dass ein großer Teil des sogenannten Groovy-Codes, den Sie schreiben, tatsächlich domänenspezifischer Sprachcode (DSL) ist. (Um es kurz zu machen, DSLs sind Short-Hand-Groovy, die Tatsache ausnutzend, dass in Groovy und viele der Syntax optional ist.) Grails verwendet verschiedene DSLs für verschiedene Konfigurationen, URL-Mapping, etc. und es ist inkonsistent. Wie Sie z. B. log4j-Einstellungen festlegen, sieht nicht so aus, wie Sie die Datenquellen angeben, und keiner sieht wie das reine Java aus, auf dem Groovy basiert. Das Versprechen von "everyone's Groovy" fällt trotzdem auseinander.

Das ist der Fall, ich sehe, woher das Play-Team kommt.

1. Zurück zur regulären Java für die Domänen, Controller, Dienste und JUnits macht Sinn.Starkes Schreiben bedeutet, dass die IDE zuverlässig mit Intelsinn, Code-Navigation, Refactoring usw. helfen kann (und somit müssen Sie nicht für IntelliJ bezahlen, wenn Sie mit Eclipse zufrieden sind.) Sie müssen mehr verbose Code schreiben, um eine starke Tool-Unterstützung zurückzugewinnen, scheint mir momentan ein gutes Geschäft zu sein. Wir werden sehen.

2. Ich mag, dass ich immer noch in den Seitenvorlagen Groovy verwenden. Ich befürchte, dass ich am Ende mehr Code in die Vorlagen schreiben werde, als ich sollte.

3. Ich habe keine Erfahrung mit JPA, aber es scheint, es ist ziemlich nah an dem, was GORM für mich tut, das ist cool.

4. Die Unterstützung von Spring IOC in Grails ist vollkommen transparent, während die Unterstützung von Play minimal erscheint; Ich denke jedoch, dass IOC viel zu oft benutzt wird, und ich bin durchaus bereit, ein Spring-XML-Mapping für den seltenen Fall zu programmieren, dass ich wirklich einen brauche. (Eine meiner offenen Fragen ist, dass ich annehme, dass JPA Transaction-Unterstützung hat, weshalb Play keine Spring dafür braucht, wie Grails, nein?)

5. Ich war noch nie ein Fan von Python, Ich habe mich geärgert, als ich gelesen habe, dass Play Python für seine Build-Skripte verwendet. Aber ich stimme zu, dass die GANT-Skripte von Grails ziemlich langsam laufen. Außerdem finde ich, dass GANT eine enorme Verbesserung gegenüber XML ANT ist, es aber immer noch schwierig ist, sich mit den ANT-Konzepten vertraut zu machen. Die Grails GANT Skripte sind ziemlich kompliziert. Also werde ich mit einem offenen Geist hineingehen.

6. Das Play "Anwendungsmodul" -Modell klingt wie das "Plugin" -Modell von Grails, das ist cool.

7. Ich bin ziemlich beeindruckt von der Play-Dokumentation, die ich bisher gelesen habe. Ich hatte eine große Anzahl von Fragen, aber die Hälfte von ihnen wurde sofort beantwortet.

Ich werde es später noch einmal berichten, wie ich tauche tiefer in

Answer 2

Ich habe Grails, Tapestry 4/5 und gerade Java/JSP/Spring/Hibernate verwendet.

Ich denke, dass dies zum ersten Mal seit langer Zeit in die richtige Richtung geht. Grails war ein wirklich guter erster Schritt, aber spielen! sieht aus wie etwas, das wirklich Beine haben könnte. Scala Support kommt in 1.1. Wenn es eine Chance gibt, kann ich meine Controller/Domain in Clojure schreiben, ich bin verkauft;)

Answer 3

Ich mag das Aussehen von Play, habe es aber nicht ausprobiert. Beim Durchforsten der Dokumente war eine der hervorstechendsten Methoden die Verwendung statischer Methoden. Aus Sicht der Komponententests macht dies die Dinge immer viel schwieriger (ich denke an Mocks) und ist eine Abkehr vom OO-Everywhere-Ansatz in der typischen Java-Entwicklung. Vielleicht ist das der Punkt, aber es ist nur etwas, das mich etwas weniger begeistert gemacht hat ...

Answer 4

Ich habe versucht, Spiel und ich bin beeindruckt. Es hat eine große Aufgabe für ein nützliches Entwicklungsmodell liefern, die ist viel einfacher als die meisten Frameworks ". Mehr als alles andere ist die Fähigkeit der Laufzeit im 'Entwicklungsmodus', .java-Dateien direkt zu parsen, eine Menge wert: einfach die Webseite im Browser neu laden, ohne ein Build-Skript auszuführen oder auf eine erneute Implementierung zu warten, ist viel Entwicklungsgeschwindigkeit wert. Die Fehlermeldungen im Browser sind auch wirklich gut. Eine andere Sache, die mich beeindruckt hat, war die allgemeine Ästhetik: Es ist vielleicht eine kleine Sache, dass die Tutorial-Anwendung tatsächlich gut aussieht (sowohl der Code und das Design der Webseite), aber dies erstreckt sich auf das gesamte Framework, die API auch als die Dokumentation.

Answer 5

Nachdem ich von einem Kollegen angestarrt hatte, schaute ich es an, folgte dem Tutorial und wurde süchtig. Die sofortige Rückmeldung direkt in Ihrem Browser bedeutet, dass Sie keine IDE verwenden müssen. Ich liebe Eclipse, aber seien wir ehrlich: Nachdem Sie einige Extras hinzugefügt haben, ist es nicht so stabil wie ein einfacher Texteditor. Auf einem Mac mit TextMate können Sie sogar auf die Fehlermeldung in Ihrem Browser klicken und TextMate erscheint mit dem Cursor in dieser Zeile.

Testen in Play ist auch schön gemacht, mit einem Knopfdruck führen Sie Unit-Tests, Funktionstests und Selen-basierte Tests.

Das Spiel ist aufregend, weil es immer noch klein und unkompliziert ist. Es verwendet nur Ameise um zu bauen und tut dies in 25 Sekunden. Zur schönen Dokumentation beizutragen, ist eine Frage der Bearbeitung der .textile-Dateien und das Neuladen der Dokumente in jeder Play-App.

So habe ich mich auf die Suche nach der Übersetzung von Scala begeben, um den Scala-Support zu ergänzen, wo es nötig ist, um es so gut wie möglich zu machen.

Answer 6

Ich benutze Play in einem kleinen Projekt, und scheint genau das zu sein, was sie gesagt haben. Aber eine Eigenschaft, die ich denke, sollte standardmäßig im Framework vorhanden sein: Fähigkeit, mit mehr als einer Datenquelle zu arbeiten (z. B. mehr als ein Datenbankschema verwenden). Dies ist das einzige fehlende Feature, das ich bisher gefunden habe.

Grüße, Uilian.

Answer 7

Ich mag es, ich benutze es für kleine Projekte und bis jetzt sieht es perfekt für den Job aus. Es gibt jedoch eine Sache, die ich sehr vermisse, die absichtlich weggelassen wurde: Trennung von Service/DAO/Model-Layern! Dokumentation sagt es klar, eines der Ziele des Spiels ist es, das „Anemic Datenmodell“ zu vermeiden: http://www.playframework.org/documentation/1.0.1/model

aber nach meiner Erfahrung der klassische Service/DAO/Model Schichten Trennung spart Tonnen Entwicklungszeit, wenn die Anwendung benötigt umstrukturiert werden! Mit Play stecken Sie fest mit statischen Methoden, die auf Play-spezifische Transaktionsverwaltung und Besonderheiten angewiesen sind ...

Allerdings viele Daumen hoch für: Entwicklungsgeschwindigkeit, Code Sauberkeit und am Ende ... Spaß!

Answer 8

Ich baue derzeit Web-Anwendungen bei der Arbeit mit Play-Framework, die massive Datenverarbeitung macht. Ich muss sagen, dass die Geschwindigkeit, die das Spiel allein bietet, signifikant ist und mehr als das, was RoR bieten kann. Außerdem ist play ein Java-basiertes Framework und daher kann Multi-Threading einfach durchgeführt werden. Weiter ist die schiere Leistung, die Sie erhalten, wenn Sie Java-basierte Module wie Japid und Netty zusammen mit dem Spiel verwenden. Es ist wie eine endlose Menge an Optimierungen für die Leistung getan werden kann. Ein muss meiner Meinung nach versuchen.

Answer 9

Seit einem Jahr und ohne sichtbaren Bug nach 18 kleinen Releases verwenden wir Play! 1.2.4 in einer Produktion "Abwesenheit" Intranet-Antrag für eine Schule (Schauspieler:> 100 Lehrer,> 700 Studenten, administrative Team). Client-Seite wurde mit FLEX 4.6 von Adobe geschrieben (sehr schöne Ansichten). Daten werden im AMF3-Format gesendet und empfangen (Cinnamon-Modul). Wir verwenden eine eigene einfache Dao-Ebene basierend auf JPA EclipseLink und MySql für die DB. Die Anwendung wird auf einem virtuellen Linux-Server gespeichert. Ich bin ein sehr großer Entwickler von Play wegen seiner Einfachheit und seines sehr produktiven Ansatzes.