「Play」の経験Java Web開発フレームワーク？
次の新しいJava Webフレームワークに出くわしました：Play
http://www.playframework.org/documentation/1.0/home
そのような驚くべき機能のリストで、私はそれを前に聞いたことがないことにかなり驚いています...
Java Web開発が約束した土地...
誰かがそれを試しましたか？それで実際の経験はありますか？勉強する価値があると思いますか？
PlayがGrailsよりも優れていることが証明されるかもしれないというJasonに同意します。私のベルトの下に4つのGrailsプロジェクト（2つのTapestryプロジェクトと1つのWicketプロジェクトが先行）があるので、私は次にPlayを真剣に検討しています。
Grailsについて私がクールだと思ったことの1つは、「すべてがGroovyだ」ということです。つまり、Groovyを使用して、ドメイン、コントローラー、サービス、ページテンプレート（GSP）、タグライブラリ、Hibernate API（GORM）、単体テスト（GUnit）、ビルドスクリプト（HTMLとCSSを除く）をすべて記述します。ガント）。 Groovyでシェルスクリプトを書くこともできます。そのため、単一の言語を使用してアプリのすべての側面をコーディングできるようになることは、長い間遅れていた単純化のように思えました。C++やDelphiなどの単一の言語でデスクトップアプリを作成していた時代を振り返ります。しかし、1つのサイズですべてに対応できるわけではないことを学びました。
1つは、IDE Groovyのサポートは素晴らしいものではありません。IntelliJは最高の仕事をしますが、Groovyは動的であるため、これまでのところしか実行できません。リファクタリングツールはキャッチしません（できません）。すべてのものであるため、100％信頼することはできません。これは、ユニットテストに特に注意する必要があることを意味します。ここでも、Grailsは実行時に発生する動的な「魔法」に大きく依存しているため、Grailsでのユニットテストはそれをエミュレートするための大規模なモックレイヤーであり、そのモッキングレイヤーは風変わりです.3番目の問題は、作成しているいわゆるGroovyコードの多くが実際にはドメイン固有言語（DSL）コードであるということです（長くするために）簡単に言うと、DSLはGroovyの略語であり、Groovyでは構文の多くがオプションであるという事実を利用しています。）Grailsはさまざまな構成やURLマッピングなどに異なるDSLを使用し、一貫性がありません。log4j設定の指定方法たとえば、データソースを指定する方法とはまったく異なり、純粋なJava on Groovyのベースです。だから、とにかく「すべてのグルービー」の約束は崩壊します。
そういうわけで、Playチームがどこから来ているのかわかります。
ドメイン、コントローラー、サービス、およびJUnitの通常のJavaに戻ることは理にかなっています。強い型付けは、IDEがインテリセンス、コードを確実に支援できることを意味します。ナビゲーション、リファクタリングなど（したがって、Eclipseに満足している場合は、IntelliJにお金を払う必要はありません。）強力なツールサポートを取り戻すために、より詳細なコードを記述しなければならないことは、今のところ私にはかなりのことのようです。 。わかります。
私はまだページテンプレートでGroovyを使用できるのが好きです。とはいえ、テンプレートに必要以上のコードを入れてしまう可能性があります。
私はJPAの経験はありませんが、GORMが私に提供するものにかなり近いように思われるので、それはすばらしいことです。
Spring IOC Grailsでのサポートは完全に透過的ですが、Playのサポートは最小限のようです。ただし、IOCは使いすぎであり、私は完全に喜んで手渡します。まれにSpringXMLマッピングをコーディングする必要があります（私の未解決の質問の1つは、JPAがトランザクションをサポートしていると想定しているため、GrailsのようにPlayがSpringを必要としない理由です。）
私はPythonのファンになったことがないので、PlayがビルドスクリプトにPythonを使用していることを読んだとき、うんざりしていました。しかし、GrailsのGANTスクリプトの実行速度がかなり遅いことに同意します。 、GANTはXML ANTを大幅に改善したものですが、それでもANTの概念に頭を悩ませることは困難です。GrailsGANTスクリプトはかなり複雑なので、心を開いて説明します。
Playの「アプリケーションモジュール」モデルは、Grailsの「プラグイン」モデルと同じように聞こえるので、かっこいいです。
これまで読んだPlayのドキュメントには非常に感銘を受けました。たくさんの質問がありましたが、その半分はすぐに答えられました。
深く掘り下げて、後でまた報告します。
私はPlayを試しましたが、感銘を受けました。ほとんどのフレームワークよりもはるかに単純な便利な開発モデルを提供するという素晴らしい仕事をしています。何よりも、.Javaファイルを直接解析する「開発モード」でのランタイムの機能は非常に価値があります。ビルドスクリプトを実行したり、再デプロイを待たずにブラウザでWebページをリロードするだけで、開発速度が大幅に向上します。ブラウザに表示されるエラーメッセージも本当に良いです。
私が感銘を受けたもう1つの点は、全体的な美学でした。チュートリアルアプリケーションが実際に見栄えがするのは小さなことかもしれませんが（コードとWebページのデザインの両方）、これはフレームワーク全体、API、およびドキュメントにまで及びます。
私はそれが好きです、私はそれを小さなプロジェクトに使っています、そして今のところそれは仕事に完璧に見えます。ただし、意図的に省略されていることが非常に見逃していることが1つあります。それは、サービス/ DAO /モデルレイヤーの分離です。ドキュメントによると、Playの目標の1つは、「貧血データモデル」を回避することです。 http://www.playframework.org/documentation/1.0.1/model
しかし、私の経験では、従来のサービス/ DAO /モデルレイヤーの分離により、アプリケーションのリファクタリングが必要な場合に開発時間を大幅に節約できます。 Playを使用すると、Play固有のトランザクション管理と特殊性に依存する静的メソッドに悩まされます...
しかし、多くの人が賛成しています：開発速度、コードのクリーンさ、そして最終的には...楽しいです！
同僚からの提案の後、私はそれを見て、チュートリアルに従い、夢中になりました。ブラウザですぐにフィードバックを受け取ることは、IDEを使用する必要がないことを意味します。私はEclipseが大好きですが、それに直面しましょう。いくつかの追加機能を追加した後は、単純なテキストエディターほど安定していません。 TextMateを搭載したMacでは、ブラウザでエラーメッセージをクリックすることもでき、TextMateはその行にカーソルを置いてポップアップします。
Playでのテストもうまく行われ、ボタンを1回押すだけで、単体テスト、機能テスト、Seleniumベースのテストを実行できます。
それはまだ小さくて複雑ではないので、遊びはエキサイティングです。 antを使用してビルドし、25秒でビルドします。美しいドキュメントに貢献することは、.textileファイルを編集し、任意のPlayアプリでドキュメントを再読み込みすることです。
このようにして、チュートリアルを翻訳してScalaを使用するという探求にたどり着き、必要に応じてScalaサポートを追加して、可能な限り素晴らしいものにしました。
Grails、Tapestry 4/5、およびストレートJava/JSP/Spring/Hibernateを使用しました。
これは久しぶりに正しい方向に進んでいると思います。 Grailsは本当に良い最初のステップでしたが、Play！本当に足ができるもののように見えます。 Scalaサポートは1.1で提供されます。Clojureでコントローラー/ドメインを作成できる可能性がある場合は、販売されます;）
1年間で、18回の小さなリリース後に目に見えるバグがないため、Playを使用しています。 1.2.4学校向けのプロダクション「不在」イントラネットアプリケーション（俳優：> 100人の教師、> 700人の学生、管理チーム）。クライアント側はAdobeのFLEX4.6で書かれています（とても美しい景色）。データはAMF3形式（Cinnamonモジュール）で送受信されます。 DBにはJPAEclipseLinkとMySqlに基づく独自の単純なdaoレイヤーを使用します。アプリケーションはLinux仮想サーバーに保存されます。私は、そのシンプルさと非常に生産的なアプローチのために、Playの非常にファンの開発者です。
Playの外観は気に入っていますが、試したことはありません。ドキュメントをスキャンしたところ、目立ったのは静的メソッドの多用でした。ユニットテストの観点からは、これは常に物事をはるかに難しくし（私はモックを考えています）、典型的なJava開発におけるオブジェクト指向-あらゆる場所のアプローチからの逸脱です。多分これがポイントです、しかしそれは私を少し熱狂させただけの何かです...
私は現在、大規模なデータ処理を行うPlayFrameworkを使用して仕事でWebアプリケーションを構築しています。プレイが単独で提供する速度は重要であり、RoRが提供できる速度を超えていると言わなければなりません。さらに、playはJavaベースのフレームワークであるため、マルチスレッドを簡単に実行できます。次は、JapidやNettyなどのJavaベースのモジュールをplayと一緒に使用した場合に得られるパフォーマンスです。パフォーマンスのために無限の量の微調整を行うことができるように。私の意見では試してみる必要があります。
私は小さなプロジェクトでPlayを使用していますが、まさに彼らが言っていることのようです。しかし、フレームワークにはデフォルトで存在する必要があると思う機能が1つあります。それは、複数のデータソースを操作する機能です（たとえば、複数のデータベーススキーマを使用する）。これは私が今まで見つけた唯一の欠けている機能です。
よろしく、ウイリアン。