21

Java Web フレームワークの学習を開始する予定です (Java API が大好きです)。既に Rails と Django を使用しています。

Java に近いものを求めていますが、J2EE の複雑さはまったくありません。

私に適した 2 つのフレームワークを見つけました。

グレイルズ

Grails は見栄えがよく、Web アプリケーションには Java よりも優れた Groovy を使用しています (私が思うに..) が、純粋な Java ベースのフレームワーク (Hibernate、Strut、Spring) よりも遅いです。 !)、GSP は素晴らしいです! デバッグが少し難しくなります (変更のたびにサーバーを再起動する必要があり、スタックトレースには Java と Groovy のトレースが混在しているため、常に理解しやすいとは限りません)。

遊ぶ！

このフレームワークも見栄えがします。Grails (Java を使用) よりも高速ですが、Java の使用方法があまり好きではありません。ソース コードを変更して、プロパティ呼び出しを setXXX/getXXX として変換します。それは好きではありません... フレームワークにはキャッシュもあります。 Grails にはない機能です。私はテンプレート エンジンがあまり好きではありません。デバッグも簡単です (サーバーを再起動する必要がなく、スタックトレースがより明確になります)

おすすめは何ですか？簡単に学べるもの (Ruby の経験は豊富で、Java の経験はそれほど多くありませんが、Java API は大好きです) を探しています。スケーラビリティが高く、遅すぎない (Ruby よりも速い) 理想的には、サポートを簡単に見つけることができるまともなコミュニティを持つフレームワークを使用したいと考えています。

PS: JRuby on Rails には興味がありません

4

6 に答える 6

29

私は Grails から Play に切り替えましたが、振り返ることはありませんでした。Grails に関する私の最大の問題は、全体的な堅牢性と開発者の使いやすさでした。ほとんどの場合、Grails が Spring MVC と Hibernate の通常のスタックをくっつけて、この事実を隠そうとし、Rails のような API を提供しているという事実に悩まされていました (私の個人的な意見です)。これに関する問題は、何かが些細なサンプルを超えると、簡単に壊れてしまい、私にとってはうまくいかないことです. それを使った開発は、（私にとって）卵の上を歩くようなものでした。必要な機能のドキュメントをグーグルで検索すると、サンプル、チュートリアル、ブログではなく、Grails JIRA にリダイレクトされ、その機能が私のユース ケースで機能しない理由と、1 つ前の 2 つのバージョンからバグが解決されていない理由が説明されました。使っていました。

これはすべての開発者にとっての全体的な経験ではないかもしれませんが (Grails をバッシングするためにこれを書いているのではなく、Grails での経験をここに示すために書いているのです)、私には何か助けになるもの、邪魔にならないもの、失敗したときに必要なものが必要でした。一番必要でした。それが私が Play を見つけたときで、それを知った後 (~1.0 リリース前後)、すぐにアプリをそれに移行しました。

これまでのところ、それは素晴らしい道のりであり、Web 開発のキャリアの中で初めて、より良いものを見つけようとして他のフレームワークを見るのをやめました。

Play が Grails よりも優れている点を 1 つ挙げて締めくくらなければならない場合 (少なくとも私にとっては)、それは、Play がゼロから開発者の使いやすさを念頭に置いて構築されているという事実です。企業の流行語の使いやすさを犠牲にすることはありません。このパラダイムに当てはまらないものを捨てる勇気があります (たとえば、開発中にサーブレットベースのランタイムを捨てて、ターンアラウンドを早めるなど)。素晴らしさを保証するために、喜んで妥協します。Play を見つける前は、Rails や Django などのコミュニティでしか見たことがありませんでした。

于 2011-03-08T17:05:04.653 に答える
23

私はGrailsをお勧めします。Play フレームワークよりも大きなコミュニティがあります (ほぼすべての基本的なニーズをカバーする約 350 のプラグイン)。また、grails はほぼ完全に Java で書かれており、Groovy をドメイン固有の実装に使用できるようにするだけです。

作成したグルーヴィーなページがボトルネックとなってパフォーマンスの問題が発生した場合は、いつでも Java 実装に切り替えることができます。そうすると、Play フレームワークをずっと使っていたのと同じボートに乗ってしまいます。実際にそれを行う必要があることがわかるまで、Java でのコーディングを延期することで、開発時間を最適化しました (私の経験では、これは非常にまれです)。

また、変更ごとにサーバーを再起動する必要があると聞いた場所もわかりませんが、実際にはそうではありません。Grails は、サーバーを再起動せずにコントローラー/gsps/サービス/ドメイン オブジェクトなどの再読み込みをサポートします。

混合スタック トレースは少し長くなる可能性がありますが、ツール ベンダー (Intellij など) は、気にしないすべてのスタック トレース部分を削除するいくつかの最近の改善を行いました。

私は 0.5 日間から grails を使用しており、このプラットフォームに非常に満足しています。

于 2010-03-27T19:16:20.313 に答える
3

私の Play での経験からすると、これは素晴らしいフレームワークです。私のお気に入りの機能は、クールなコントローラー システムとテンプレート システムです。どちらもシンプルですが、機能が豊富で強力です。

しかし、Play の最も重要な利点は間違いなく迅速な開発サイクルであり、コードの変更時に実質的にリロードが必要ありません。しかし、注意を怠ると、この優れた機能は長続きせず、最終的にコードに速度の低下が忍び寄るでしょう。

何故ですか？Play では、EJB (Hibernate) や Spring など、かなり重い初期化を伴ういくつかのプラグインが一般的に使用されます。これらのプラグインの初期化は、新しいコードがロードされる前にコードが変更されるたびに再実行されます。この結果、モデルとシステム構成が大きくなるにつれて、この重い初期化によって開発が大幅に遅くなります。私が使用したシステムでは、Kickass ラップトップで実行されている仮想マシンの典型的な起動時間は 20 秒でした。

これを回避するためにできることは、アプリケーションによって異なります。たとえば、NoSQL アプリケーションを構築している場合、EJB プラグインで問題が発生することはありません。Spring はカスタムのハードコーディングされた Java プラグインに置き換えることができます。これは IMHO の方が保守も簡単です。または、スクリプト可能性が重要な場合は Groovy スクリプトを実行します。いずれにせよ、これらの問題に注意し、若いうちにそれらを強制終了してください。また、更新のたびに独自の大規模な初期化を実行しないようにしてください。

于 2011-12-04T22:24:15.130 に答える
3

Play ! フレームワークは 1.1 でScala の使用をサポートするようになりました

于 2010-11-15T03:52:52.270 に答える
1

以前に Ruby と Python を使用したことがある場合は、おそらく Play よりも Grails の方が楽しめるでしょう。これらの動的言語に慣れると、Java に戻るのは非常に困難です。

于 2010-03-27T19:15:35.633 に答える
0

Lift on Scalaもあります。
Imho scala は最高の静的型付き言語であり、lift はかなり優れたフレームワークです (静的型付き言語の場合)。

于 2010-03-27T18:10:44.997 に答える