88

これは半分暴言、半分質問です。

Grails を使う価値はありますか? 比較的単純なデータベース駆動型の Web アプリケーションを開発しようとしています。私の専門は Java であるため、当然、Grails が適しているように思えました。最初は、Spring、JPA、および Hibernate を使用することを考えていましたが、以前はそれを使用しており、あらゆる種類の面倒な構成およびコーディング作業に遭遇しました。Grails は、これを解決していると宣伝しています。

Grails に対する私の最大のフラストレーションは、すべてが機能しないことです。私が言いたいのは、直感的に思うように機能しないということです。エッジのあたりがかなり荒いです。私は絶えず問題に遭遇します。Grails に対する私の理解不足が原因である場合もあれば、正当な Grails バグを発見した場合もあります。

主要な問題の 1 つは、適切な Eclipse 統合の欠如です。Groovy と Grails のプラグインがありますが、シンタックス ハイライト以外の機能はほとんどありません。Java から Groovy を呼び出したり、Java から Groovy を呼び出したりするのは非常に面倒です。優れた IDE サポートがないことは大きな問題です。

何が起こるかというと、私は座って Web アプリケーションを開発しようとしています。1 日の終わりに、1 日の約 85% を Grails 関連の問題のデバッグに費やしていることに気付きました。Eclipse の問題でない場合は、熱心な読み込みビューでのフェッチ1 対多の関係空のファイルの奇妙な動作プロパティ/getter の奇妙なバグです。これは、今日遭遇した問題のほんの一例です。Grails との最後の座談会では、さまざまな問題が多数発生しました。

価値があるのだろうかと思うことがあります。他の人がこれを経験したかどうか興味があります。実際に Grails を使って生産的に Web アプリケーションを作成している人はいますか? 検討すべき迅速な Web 開発のための他のフレームワークはありますか?

4

15 に答える 15

85

Grails を 0.6B から学んだ経験豊富な上級 Java 開発者である 12 人のチームがあり、現在も全員が Grails に基づくプロジェクトに取り組んでいます。喜んで Java に戻るつもりはありませんが、Grails アプリケーションを使って簡単にどこかへ行く方法の裏をかくことができて、私たちは皆ほっとしています。

それは苦労でした。簡単ではありませんでした。フラストレーションがありました。

それにもかかわらず、継続的な努力により、非常に迅速に何かを提供しました.バグがあり、多くには回避策があります.

Java が得意な開発者が、Grails プロジェクトの深く複雑な呪文に飛び込もうとしている例をいくつか聞いたことがあります。すべての Java を避け、純粋な Grails と Groovy に移行しました。私たちは、単純なものから始めて、複雑さを可能な限り管理しやすく実用的に構築したことを確認しました.. 私たちは、Java の知識が私たちを運ぶのに十分であることを願っています.

私たちは最終的に、純粋な Java/Spring/Hibernate バージョンを作成するよりもはるかに高速に動作する、素晴らしく機能する巨大で複雑なものを作成しました。それは適切な IDE サポートがなく、バグの点で今日よりもはるかに悪い状況です。

Eclipse のサポートに関しては、Grails/Groovy に使用する唯一の実際の IDE は Intellij です。悲しいことに、Eclipse のサポートはかなり遅れています。私は Eclipse の愛好家であり、Intellij への変換者ではありません。Grails/Groovy のサポートは他のすべてを吹き飛ばします。けれど。

はい、Grails はおそらく Spring に比べて未熟です。または休止状態。そして、彼らの存在の最初の 1.5 年間は、同じように問題を抱えていたと私は賭けます。

現状では、複雑さを最小限に抑え、(私たちの意見では) 最初に慎重にテストし、徐々に慎重に複雑さを構築する責任があなたに課せられます。

スタックに Spring/Hibernate を組み込むと、Java を使用した高速なコード ソリューションはありません。Grails が体現する複雑さは、Spring や Hibernate 自体の複雑さを反映しています。ピュア Java を使ったほうがいいと思うなら、それ以外の議論はしません。私はまだ WTF を持っていますが、急な学習曲線は過ぎ去ったので、もう少し Grails を使い続けると思います。

于 2008-12-29T08:02:59.763 に答える
36

私は2つの理由でgrailsアプリケーションを書くことをとても楽しんでいます:

  • Javaを使う必要はありません
  • Javaを使用できます

グレイルに慣れた後、彼のことは非常に迅速かつエレガントに行われると思います。

プラス面についてはこれだけです。マイナス面はパフォーマンスです。これは、デプロイメントとテスト駆動開発の2つの側面に影響を与えます。

メモリとパフォーマンスの制限にすぐに達したため、1台の(レンタルした)サーバーで3つを超えるgrailsアプリケーションを実行することはできませんでした。含まれているフレームワークが多すぎます。

さらに、grailsのテストランナーはその名前の価値がありません。単体テストを実行するときは、10〜20秒ではなく、瞬時に実行する必要があります。ですから、私はいつもプレーンJavaでビジネスロジックを書いていることに気づきます。なぜなら、それをはるかに速くテストできるからです。しかし、これはIDE(Eclipse)へのより良い統合で対処できると思います。

于 2008-12-29T20:34:44.270 に答える
10

Spring による Grails のサポートは、大きな後押しになると思います。誰かが Web 上の CRUD を通過できるとすれば、それは彼らです。

また、クリティカルマスに達していると思います。2009 年にはいくつかの新しい書籍が市場に出回る予定です。これらは採用率を高めるのに役立つと思います。

于 2008-12-29T14:46:17.670 に答える
9

元のポスターの感情に完全に同意します。

私たちは Java + Spring ショップであり、この機会に Grails を試してみました。最初に非常に小さなテスト アプリケーションを作成しましたが、非常に簡単に実行でき、非常にうまく機能しました。ここで発生した主な問題は、Groovy と Grails に関する知識の不足によるものでした。

この成功 (信頼度の向上) に続いて、少し大きなプロジェクトを試みることにしました。これは、はるかにつらい経験でした。他の人が述べたように、私たちは表面上はすぐには明らかにならなかったあらゆる種類のバグや問題を発見しました。アプリの再起動サイクルは非常に苦痛であり、非常に優れたテスト カバレッジがない限り、あらゆる種類のリファクタリングを行うのは悪夢です。

エラー メッセージが 1 つも表示されずにコードが失敗するのは、本当にもどかしいことです。うまくいかないだけで、その理由がわかりませんか?

JMS、Quartz、Remoting などのプラグインの使いやすさが気に入っています。多くの退屈な XML を排除します。

いくつかの問題もありましたが、私はそのシンプルさから GORM が好きです。

Groovy の緩い型付けの性質と、一連のエラーをキャッチするためだけにアプリケーションを実行する必要があるという事実が好きではありません。PHP や Rails を思い出しすぎます。

結局のところ、Grails を使用して複雑な管理可能なソフトウェアを作成できるかどうかを自問しています...

Grails アプリケーションが本番に入る予定です....それで様子を見ていきます。

于 2009-05-05T14:52:38.077 に答える
7

私はRubyonRailsの経験が、Javaの世界の何よりも多いので、別の視点からやって来ています。全体として、GrailsRailsよりもはるかにラフです。これは、一部は未成熟であり、一部は2つの非常に複雑なフレームワーク(SpringとHibernate)に依存しているためです。Railsにはさらに大きなコミュニティもあります。

しかし、言語としてのGroovyは大きな進歩を遂げており、一緒に仕事をすることを楽しみにしています。Groovy 1.6で行われた改善のおかげで、GrailsはJRuby on Railsよりもかなりスッキリしており、GPathを介して驚くほど優れたXMLサポートを利用できます。JVMを使用することで得られる優れた機能(並行性や大量のスレッドセーフコードなど)はたくさんありますが、Java(私はあまり気にしない言語)をいじくり回す必要がないので、私は本当に持っていますMRIで何かを使用するように自分を納得させるのに苦労しました。

Pythonは魅力的に見えますが、私は認めなければなりません。

あなたのEclipseの問題に関しては、私は助けることができません。私はVimとEmacsを使用していますが、これは主にIDEを使用して我慢できないためです。ただし、Groovy、Ruby、Pythonなどの動的言語の場合、コード生成やコンパイルの必要性が実際にはないため、IDEが実際にメリットをもたらすとは思いません。たぶん、しばらくの間IDEを使用せずに作業してみて、状況がよりスムーズかどうかを確認してください。

だから、ええ、Grailsはそれだけの価値があると思います。彼らは物事をできるだけ早く機能させるために地獄のような仕事をしました、そしてGrailsとGroovyチームは両方とも本当に本当に献身的です。

于 2009-04-04T04:42:00.263 に答える
6

私は完全にあなたと一緒です!Grails はまだ端が荒いので、Rails と比較するのはほとんど冗談です。少なくともエラー報告が少し良くなった場合。しかし、それはおそらく、裏で使用する膨大な量のライブラリによるものだと思います。一言:スタックトレース!私はまた、model->db アプローチの大ファンではありません (Rails には db->model があります)。足場も改善の余地がたくさんあります。次に、「再起動不要」も宣伝どおりに機能しません。(何が悪いのかわかりません-常に再起動する必要があるか、再起動すると消える奇妙な動作を見つけることがあります)そして、GORMを始めさせないでください。(単純な SQL だったはずの方法を見つけるのに何時間もかかると、この ORM 全体が本当に時間を節約できるのか疑問に思うようになります) 単純である限りは。

つまり、Java の世界から来た場合でも、フレームワークのより良い選択の 1 つです。(自分自身を Web フレームワークと呼んでいる役に立たないがらくたがたくさんあります) ...それには可能性があります。他の多くの複雑なものの上に構築されていないことを願っています。

とにかく、これらが整理されることを願いましょう。現在、私はplayframework.orgに潜んでいます。これも非常に滑らかで有望に見えます。

于 2009-01-10T00:15:02.430 に答える
4

彼らがEclipseプラグインを終了するとき、それは価値があるでしょう。早ければ早いほど良いと思います。上司にグルーヴィーを売ろうとするのは、それが起こるまで簡単なことではありません。

于 2008-12-29T20:08:54.477 に答える
4

Grails の最大の利点は、データベースを気にする必要がなくなったことです。スキーマは自動的に作成/更新され、永続化はほとんど私のために行われます (SQL クエリを記述する必要はありません)。これは大きな安心です。もう 1 つの優れた点は、コントローラーとビューのテンプレートが決まれば、新しいドメイン オブジェクトの追加が非常に高速になることです。少なくともビューに対して継続的な変更を行い、それらを既存のビューにバックフィットすることになると思います。

IDE に関しては、IntelliJ が最適なオプションのようですが、私は Netbeans 6.5 を使用して満足しています。私は他のすべての開発に MyEclipse を使用していますが、Netbeans は Grails のサポートが向上しています。

于 2009-01-19T15:51:09.887 に答える
3

私は新しいプロジェクトで grails を使い始めたばかりです...xml ファイルを作成する必要はありませんが、Spring と Hibernate のパワーは本当に素晴らしいです。

ただし、IDE には IntellijIDEA を使用します。実際には、IDE を通じて Grails を発見しました (偏見があるかもしれませんが、 Eclipse は嫌いです)。

于 2009-02-26T21:12:24.880 に答える
3

私は Grails を使い始める前は Eclipse ユーザーでした。それがうまくいかないことはすぐに明らかになりました。そこで、Intellij と NetBeans を試しました。当時、Groovy と Grails に関する限り、Intellij の方が優れていました。しかし、NetBeans は無料だったので、私には十分でした。それ以来、3 つすべてに新しいバージョンまたは新しいプラグインがリリースされています。Intellij のコストのために、私はまだ NetBeans を使用しています。Spring Source による G2One の買収により、期待の 1 つは、Eclipse での Groovy と Grails のサポートが強化されることです。これは、採用を増やすために必要です。

新しいプロジェクトに Grails を使用するのは素晴らしいことです。Enterprise Java のお荷物の多くは、もはや必要ありません。フレームワークの長所と短所がどこにあるかを理解するまで、それを効率的に利用するのは難しいため、何かを移植しようとするのは難しいと想像できます。Grails 1.1 では JSP のサポートがより簡単になることが約束されていますが、新しいフレームワークを理解するためにベータ版を使用することが良い考えかどうかはわかりません。テストは、新しいバージョンのメジャー リビジョンも通過しました。時間が許せば、1.1 のリリースはすぐに来るので、待つことを検討してください。

プロジェクトをゼロから開始する際に、別の IDE で Grails を試してみる機会があれば、別の視点から見ることができると思います。

于 2008-12-30T13:44:40.167 に答える
2

完全に。非常に多くの Java フレームワークがあり、新規参入者のハードルは非常に高く設定されています。これは、Grails がこのように混み合ったスペースで上を行くことができた証です。

それはまだいくつかの鋭いエッジを持っていますが、それらがマットダウンされるのは時間の問題です.根底にあるプロジェクトは非常に価値があります.

于 2009-01-15T23:38:43.467 に答える
1

Grails は、(最初の初期化で作成された多数のファイルと必要なリソースに基づいて) アプリケーションの種類に対して大きすぎる可能性があります。シンプルなものを探しているなら、Grails はあなたが探しているものではないかもしれません。シンプルで機能するものを探しているなら、これまでのところ、django がうまく機能すると思います。チュートリアルから CRUD アプリを作成するのがいかに簡単か (必要なファイルの数) を見てみましょう。ここから、ニーズや要件の拡大に合わせて、アプリを (比較的) 簡単に拡張できます。

于 2009-07-21T11:30:00.123 に答える
0

彼らがあなたが知っているようにGrailsを正しく作ることができるかどうかはわかりません。そして、正しいことは、最終的にはもろくて壊れやすいと感じるすべての詳細(小さいものと大きいもの)に対処することを意味します。その背後に実際の開発チーム(2人以上を意味する)があるかどうかさえわかりません。

Grailsプロジェクトの機能を繰り返して、何かを改善しようとするたびに、それは同じワークフローです。すべてがバラバラになり、100回の「google」テストサイクルになり、実行できない理由がわかります。あなたが望むこととあなたは何か他のことをします。

結局、実行されているものには触れたくないので、イライラします。そして、うまくいかないものは、あなたはそれらを落とします!

JRuby経由でRailsへの切り替えを検討しています。それは両方の世界で最高かもしれません:アクティブで大規模なコミュニティを備えた有能なWebフレームワーク、開発者の専用チーム、SpringやHibernateのような疑わしい複雑なフレームワークに基づかないプラットフォーム、迅速で野心的なリリースサイクル。そして、JRubyは、率直に言って、バックパックにJavaアセットがたくさんあるので、それらを捨てることはできません。

于 2009-02-19T17:19:34.933 に答える
0

あなたが言うように、あなたの専門知識がJavaにある場合。Play Frameworkをご覧ください。これは、Ruby on Rails に触発された非常に短い開発サイクルの Web フレームワークです。Java ソース ファイルを保存し、Web ブラウザーを更新するだけです。また、別の言語を試してみたい場合は、Play Framework に、代わりに Scala を使用できるモジュールがあります。

Play Framework は分かりやすく、パフォーマンスも良いので気に入っています。必要に応じて、ORM レイヤーに JPA と Hibernate を使用することもできます。

于 2011-07-09T08:31:06.477 に答える