72

これが重複していることは承知していますが、Grails の世界は、この質問が 1 年以上前に出されてから大幅に進歩しており、Eclipse での IDE サポートもそうであるため、やみくもに閉じないでください。

私は答えはイエスだと思い、Grails 1.2.0で新しいプロジェクトに着手し、 STS Eclipse Integrationの Groovy/Grails のビットをいじりました。

Grails の 1 年間の進化の後、答えが完全にまちまちだったので、この質問を再検討する価値があると思います。

したがって、経験豊富な Java Web 開発者として、私はこれらの質問を持っています。

  • Grails は今、Ruby と比べて価値がありますか?
  • バグのあるスタートを克服しましたか？
  • それは本当に迅速な開発の利点をもたらしますか? (リストやページ指向ではない特注のアプリを作成するための広範なベースライン構成を過ぎてしまったので、今は苦労していることを認めます)
  • 実際の運用アプリで機能しますか? （重く感じる）
  • Eclipse プラグインは以前よりも優れていて、目的に合っていますか? （まだだと思います）

ありがとう

編集： 私は、フレームワークの機能自体ではなく、フレームワークと一緒に暮らすことについていくつかの重大な不満を抱いています。私がこれらを追加しているのは、それらが考慮すべきことであり、私の経験と意見に基づいており、grails に行くかどうかを決定しようとしている人を助けるかもしれないからです. また、フレームワークの経験不足を示している可能性もあるため、これは完全な批判を意味するものではありません。私は経験豊富な開発者であり、これが私が見つけたものです:

デバッグは本当に大変です。実際、特にフレームワークの初心者にとっては、信頼できるデバッガーの友人が最も必要な場合はほとんど不可能です。スタックのどこかでサイレント エラーを引き起こすドメイン フィールドの参照に関係するコードの一部の構文エラーの問題を追跡するのに、本来よりも多くの時間を費やしました。

ロギングは率直に言ってひどいものです。「何の役にも立たない」と「途方もない量の役に立たないもの」の 2 つのモードがあります。単一のページ リクエストの後のデバッグ ログは 128Mb で、エラーについては何も含まれていません。私の意見では、ロギングの問題全体をフレームワークで再検討する必要があります。

STS Eclipse IDE の価値はわずかです。シンタックス ハイライト以外はあまり役に立ちません。コードをデバッグすることはできないため、美化されたエディターです。コードのヒントはパッチだらけで、私が見る限り GSP のサポートはまったくありません。また、私のデスクトップにある Eclipse プラグインの中で最も遅く、起動に約 2 分かかります。驚くほど遅いです。テキスト エディター (すべてのオンライン チュートリアル ビデオでも使用されていることがわかります) とカスタム構文の強調表示に戻りました。

パフォーマンスについて深刻な懸念があります。言うには時期尚早ですが、休止状態のためにデータベースを微調整していることにすでに気付いています。当然のことかもしれませんが、パフォーマンスの高いクエリを生成する規則のために、ドメイン モデルをシンプルに保つ必要があります。

最後に、論理ドメイン モデルと物理データベース モデルを同一にするという規則は、スマートな既定値ではなく、現実の世界ではありそうもないことです。2つを分離できることはわかっていますが、ある程度の複雑さが生じますが、規則が拡張されていれば回避できると思います。合成と、それを実際に機能させるために何をする必要があるかについてのドキュメントが不十分です。

4

21 に答える 21

56

私はGrailsを4か月以上使用していますが、Grailsとその使いやすさについての個人的な感想をお伝えしたいと思います。

Grailsは、Rubyや他のロールと比べて価値がありますか？

もちろん、答えは「はい」または「いいえ」ではありませんが、それは異なります。それはあなたの要件（あなたはJavaの世界にいる必要がありますか？）、あなたの好み（あなたはドメイン指向の開発を好みますか、あなたはGroovyを好みますか...）にも依存しますか？ただし、GrailsはRailsの真剣な代替手段であると答えることができます。Railsアプリケーションが何であれ、Grailsでも実行できると思います。ただし、プロジェクトの性質によっては、多少時間がかかる場合があります。繰り返しになりますが、Railsに精通しているが、Grailsに精通していない場合は、Railsがより安全なオプションです。

それはそのバグのあるスタートを克服しましたか？

はい。私の最初のメッセージ（このWebサイトまたは他のWebサイト）を見ると、Grailsのバグについて多くの不満がありました。ただし、Grailsはエッジが少し荒い（たとえば、ドメイン継承をあまり使用しない）ことを覚えておく必要があります。フレームワークに慣れれば、それほど悪い驚きはありません。Grailsがバグではないと言っているのではありません。それは確かにRails以上のものです。しかしまた、それはバギーよりも使いやすいです。そのためのアドバイス：できるだけ少ないプラグインを使用してください。それらの多くはバグがあり、いくつかはそれらの間で互換性がないためです。したがって、grailsプラグインが最新で、邪魔にならず、（自分で）テストされていることが確実でない限り、grailsプラグインを含めないでください。

それは本当に迅速な開発の利益をもたらしますか？

はい。DB設計を扱う必要はほとんどありません。設定より規約のおかげで、設定はほとんど最初から完了します。アプリケーションは簡単に保守できます。私が見る唯一の欠点は、他のテクノロジー（RailsやASPなど）ほど豊富ではないフロントエンド開発です。

実世界の本番アプリで機能しますか？

私はまだ自分のウェブサイトを公開していなかったので言えませんが、sky.comはGrailsを使用しており、サイトは1日あたり約700万ページのトラフィックを集めているため、かなり自信があります。この場合も、パフォーマンスはアプリケーションアーキテクチャと設計上の決定に大きく依存します。

Eclipseプラグインは以前よりも優れていて、目的に適合していますか？

わからない。私はIntelliJを使用していますが、Grailsの領域で目にする不満のメッセージによると、1年前よりもはるかに良くはないと思います。

お役に立てば幸いです。

于 2010-01-13T09:22:57.130 に答える
41

最近 Rails プロジェクトを開始し、Grails でいくつかの作業を行っていました。

Railsに関する私の主な点は、開発者にとって完全に不透明なものがたくさんあることです (これは私は嫌いです)。これは、プラグイン/ジェネレーター/ライブラリ/etc を追加し始めると増加する傾向があります。何かを修正する必要があります。rails+pluginsは、 plugins+versionsの間違った組み合わせを使用すると機能しなくなる巨大な DSL ハックに過ぎないと感じます。

Grailsを使用すると、エコシステムははるかに小さくなりますが、すべてが比較的一貫している傾向があります。DSL のアプローチはあまり使われておらず、従来の退屈な設計 (DSL の代わりにクラス、インターフェースなどを使用することを意味します) を使用することで、配管がどのように機能するかを理解するのがはるかに簡単になります。

1 対 1 で比較すると、次のようになります。

  • 言語実装: 私は Ruby をよく知りませんが、Groovy よりも Ruby を好みます。Groovy は、いくつかの機能が構文の上に溶接されている、善意の悪意のある実装言語のように感じます。ハッキングを許可するためだけにあると思われるいくつかの特別なクラスについて言及しています。
  • フレームワークの特徴: Rails はこの点ではるかに優れています。Rails のほとんどの側面 (例: レイアウト、テンプレート、css/js パッカー、検証、テスト フレームワークなど) は、いくつかの方法で構成できます。Grails はこれに遅れをとっていますが、ほとんどのユースケースには十分な柔軟性があります。
  • プラグイン: Rails には、祝福または悪夢と見なされるプラグインがたくさんあります。一部のプラグインはメンテナンスされておらず、他のプラグインは一部の機能またはプラグインでうまく機能せず、多くのフォークがあります。私は基本的で最もよく使われるプラグイン (authlogic、haml など) に固執することを学んでいます
  • テスト: Rails にはテストの方法がたくさんありますが、これは必ずしも良い方法ではありません。一部のテスト フレームワークは、一部のプラグインなどとうまく連携しません。Grails にはテスト プラグインが少ないですが、いくつかの主要なプラグインとよりよく統合される傾向があります (統合するプラグインがそれほど多くないため)。
  • データベース: Grails が圧倒的に勝っています。
    • データベースをハッキングするよりも、ドメイン クラスをモデル化する方が好きです。
    • Hibernate (ボンネットの下で使用されます) は、Rails の対応物から何年も離れています。Rails 用のデータマッパー (ActiveRecord よりも本質的に Hibernate に似ています) はありますが、十分に成熟していないと感じています。Grails には、プラグインによる移行もあります。
    • Hibernate 用の優れたキャッシュ実装 (JBoss キャッシュ、EhCache など) があり、パフォーマンスを大幅に向上させることができます
  • ライブラリ: Ruby には NoSQL やクラウド サービスなどの新しいもの用のライブラリがたくさんありますが、Java には Excel 処理などの古いもの用のライブラリが無数にあります。Java ライブラリは通常、Ruby よりもはるかに高速であることを忘れないでください。
  • 最先端: Rails は誇大広告であり、その背後にはより多くのリソースがあります。これは、MongoDB や Riak を Rails に統合しようとしている場合、誰かが既に行っているという良い変更があることを意味します。Grails が遅れている主な理由は、あまり人気がなく、コミュニティが NoSQL などの最先端のものをすべて使用するのではなく、日常の問題を解決することに集中する傾向があるためです。

次に例を示します。

  • ほとんどの grails プラグインは、モデルやサービスの形式でコードを生成します。残りは通常、ライブラリによって処理されます。モデル/サービス コードを調べて、その機能を確認し、変更することができます。
  • ほとんどの Rails プラグインは通常、Rails API に接続します。つまり、何らかの関数を呼び出したり、何らかのモジュールを含めたりして、プラグイン独自の DSL を使用することになります。これは機能するときはうまく機能しますが、壊れるとひどいものになり、最終的にいくつかのものにパッチを当てるか、別のプラグインまたはプラグインのバージョンをインストールする必要があります. 熟練した Rails 開発者はこれに慣れていると思いますが、私はそうではありません。

結論：

  • 最先端の技術が必要な場合は、時折のパッチ適用を気にせず、大規模なコミュニティを支持し、ActiveRecord スタイルの DB を使用してもかまいません。Rails を使用してください。その上、言語としての Ruby は非常にエレガントです。
  • DSL ではなくクラス インターフェイス設計を好み、モデルを使用してアプリをモデル化することを好み、優れた機能は必要なく、Java エコシステムに精通している場合は、Grailsを使用してください。
于 2010-09-05T12:49:26.030 に答える
17

それは非常に価値があります！

私たちはいくつかのプロジェクトで Grails を使用していますが、そのすべてが次の理由で大きな成功を収めています。

  • 簡単 - これまで使用したフレームワークの中で最も簡単なフレームワークの 1 つです

  • レガシ コードの再利用 - レガシ コードを取得して lib または src フォルダーに配置するだけで完了です。私たちにとっては素晴らしいことです。

  • レガシー データベース構造 - レガシー データベースでデータの視覚化を生成したい場合、これは素晴らしいツールです。

さて、生存率について：

  • バグ: バージョン 1.1 以来、あまり多くのバグに直面していません (バージョン 1.0 は私たちにとってあまりにもバグが多すぎました)。

  • ツール: Netbeans はこの面で本当に改善されていますが、Intellij IDEA のような他のツールにさえ近づいていません (素晴らしいサポートです!)。Eclipse についても同じことが言えます。

  • 移植性: プロジェクトで単一の問題に直面したことはありません。

于 2010-01-13T15:06:56.747 に答える
9

現在、6 つの Grails アプリケーションが運用されています。Grails は Java フレームワークとは異なり、学習に時間がかかりますが、アジャイル手法を使用したため、成果が得られました。詳細：

  • IntelliJを使用しています。それはそれほど高価ではなく、数週間で返済されました.
  • すべての動的言語コードと同様に、自動テスト、継続的統合、およびリファクタリングは必須です。すでに TDD を実践している場合、または少なくとも適切なテスト コード カバレッジがある場合は、余分な作業は追加されません。
  • Hibernate にはデフォルトで Grails が付属していますが、他の永続化フレームワークを使用することもできます。現在利用可能なその他の 5 つの永続化プラグインがあります
  • Graeme Rochers 氏にとって伐採は明らかに問題ではありませんでしたが、着実に改善されてきました。ただし、エラーがログに記録されないという問題に直面したことはありません (コードで例外を正しくキャッチする必要があります)。
  • デバッグは明らかに注目されていませんでした (しかし、これは改善されていません)。とにかく、デバッグに依存しません。

とはいえ、すべての新しいテクノロジーと同様に、プロトタイプの作成、コード レビュー、ペア プログラミング、およびコンサルティングも利用することをお勧めします。

于 2010-07-19T13:24:36.293 に答える
7

それは非常に価値があります。1年以上愛用しています。以前はこのような高度なツールを敬遠していましたが、仕事のやり方が変わりました。1.2 リリースでは、スタック トレース情報が改善され (特に GSP の場合)、さらに改善されました。

スケーリングに関して私が経験した唯一の問題は休止状態であり、それはキャッシュであり、実際には grails の問題ではありません。一般的に休止状態が嫌いな人でも、grails が GORM でそれをラップする方法は、私にとって芸術作品です。クライテリア クロージャーの側面は、一緒に作業するのに最適です。

于 2010-01-22T21:26:44.690 に答える
6

Grails と Rails の両方に精通していて、Grails を好む人をまだ見つけていません。

両方をよく知っているなら、ほぼ確実に Rails の方が好きです。

Grails は通常、プラットフォームの変更を恐れる Java 開発者にアピールします。

この場合、老朽化し​​ たレガシーjvmにアジャイルアプローチを採用するには、JRubyがおそらくより良い方法だと思います。

于 2010-11-30T21:17:50.930 に答える
5

最近 Grails をプロジェクトに使用したので、標準の J2EE アプリケーション開発と比較した経験を共有したいと思います。

それは本当に迅速な開発の利点をもたらしますか?

確かにそうです。仮に足場の道が早々に放棄され、慣例が独自のニーズに上書きされたとしても、多くの異なるテクノロジーを気にする必要がないため、開始期間は非常に短いです。このような軽さにより、作業が速くなるだけでなく、より正確でクリーンになります。

タグを書くことは決して簡単ではありませんでした。JSF では最初に努力する価値があるかどうかを検討しましたが、Grails ではそれを行うだけです。テスト駆動型の作業と高いカバレッジ率の達成も非常に簡単ですが、さまざまなテスト ケースとモック戦略には一貫性がなく、バグがある場合があります。

Java から Groovy への切り替えは大きな喜びです。リストとマップのリテラル、クロージャ、ビルダーを使用して、Java でのボイラー プレートの「マップ」実装を破棄し、コンパクトで意味のある、焦点を絞ったコードを記述することが大好きでした。

開発速度を遅らせているのは、私たちが使用している IntelliJ プラグインにも当てはまる、完全ではない IDE サポートです。さまざまな場所に散らばっている悪い、しばしば古く、さらには間違ったドキュメント (「検索は終了しました」という約束を破る) も、急速な開発の妨げになります。そのため、ソース コードの読み取りに戻る必要がしばしばありましたが、その後、基盤となる Spring クラスの階層構造におびえていました。

于 2010-07-21T08:34:54.437 に答える
5

約 10 個のアプリケーションで Grails を使用した 3 年間の経験を共有します。Ruby on Rails と比較することはできないので、他の質問にお答えします。

バグのあるスタートを克服しましたか？

  • はい、あります。Grails 2.0.4/2.2.4 でいくつかの Grails バグを経験しました。

それは本当に迅速な開発の利点をもたらしますか?

  • 学ぶのはとても簡単で、開発も簡単です。Java の世界をよく知っている人で、基本を理解するのに 1 週​​間以上かかる人は見たことがありません。メンテナンスも簡単。また、DB についてあまり心配する必要はありません。

Eclipse プラグインは以前よりも優れていて、目的に合っていますか?

  • IDE は慎重に選択してください。Eclipse は私を大いに助けてくれましたが、クラッシュして必要以上の問題を引き起こします。私は IntelliJ を選びましたが、試用期間中は IntelliJ の方が適しているように思えました。最近、Sublime Text、いくつかのプラグイン、古いコマンド ラインを使用しています。私は特別な状況でのみ IDE にアクセスします。たとえば、デバッガーを使用する場合などです。

実際の運用アプリで機能しますか?

  • ちょっと重いです。モデルを作成する前に、設計の選択についてよく調べてください。優れた Grails 設計について多くの調査を行います。2 年前に行ったことのほとんどは、経験を積んだ今なら、より良くする方法を理解できます。実世界の本番アプリをうまく処理しますが、ミスによっては、Hibernate が本当に頭痛の種になる可能性があります。
于 2015-05-22T12:32:28.610 に答える
4

私は Grails を 1.0 ベータ版の非常に初期の頃から使用しており、Groovy/Grails を真剣に考え始めることをお勧めできるのは、Java ショップから来た場合だけです。

あなたが Java ショップで、Ruby Rails を検討しているなら、やめて Grails に行きましょう。grails が機能しない場合は、いつでも Rails を開始できます。

于 2011-06-14T15:38:02.100 に答える
4

デバッグは本当に大変です。 これが大きな問題だと思ったことはありません。デバッガーを接続してウォークスルーするか、コードに大量の println/logs を貼り付けて、何が起こっているかを調べることができます。

ロギングは率直に言ってひどいものです。 スタック トレースは一般に 4 ページの役に立たない情報を提供することに同意します。ただし、このような素晴らしいフレームワークに支払う代償はわずかです。

STS Eclipse IDE の価値はわずかです。 Eclipse は、Grails のサポートが非常に貧弱です。可能な場合は IntelliJ を使用してください。私はタイトワッドですが、会社が許可してくれれば、喜んで IntelliJ にお金を払います。

于 2011-04-14T08:38:08.557 に答える
2

Grails Eclipse プラグインはクソです。理由もなくクラッシュし、Groovy の柔軟性を実際にサポートしていません。NetBeans と IntelliJ ははるかに優れていると噂されていますが、まだ試していません。

それは実行されますか？もちろんそうです。問題に十分な数のサーバーを投入する限り、Ruby on Rails でさえ機能します。ただし、Grails がさまざまな Java フレームワークとどのように比較されるかはわかりません。

それは本当に迅速な開発の利点をもたらしますか? まあ、私はまだ多くの優れた Ruby/Rails を見逃しています。Date および Enum リクエスト パラメータは自動的には認識されません (Rails にも Date に関する問題があります)。TimeCategory は標準構成の一部である必要がありますが、そうではありません。しかし、設定をほとんど必要としないものもたくさんあります。

Rails がどこにあるのかはわかりませんが (私は Rails 3 を特に楽しみにしています)、多くの Java フレームワークよりもはるかに快適に作業できます。それでも、表面下の魔法は Rails よりもはるかに深くなります。たとえば、Constraints のシステムは非常に強力ですが、侵入できない Spring の巨大な層の上に構築されており、同じ力を少し異なる方法で使用したい場合は、非常に柔軟性がありません。Rails は破壊しやすい、IME です。

その価値はありますか？はい。それは他のものよりも良い選択ですか？場合によります。

于 2010-01-13T10:06:07.760 に答える
2

私の経験では、Grails はいくつかの非常に魅力的な機能をテーブルにもたらします。これは、Grails を学習して使用する価値があることは間違いありません。

  • 敏捷性 - 従来の J2EE プロジェクトでは実装に数週間かかっていたものが、grails プラグイン システムでは通常 1 日で完了します。ajax、jquery ui、acegi、安らかな実装、スケジューラー システム、およびそれらの多くのようなもの
  • JVM で実行されるため、他のランタイム システムとその特異性を学習する必要がなくなります。

  • Java ライクな構文とグルーヴィーな構文シュガー。両方の長所のように。Ruby のような新しい言語の構文を学ぶ代わりに、すぐに Java から始めて、ゆっくりと堅牢で簡単で直感的な groovy 構文に移行できます。

    プロジェクトマネージャーにとって、何らかの理由で「使用しない」というやむを得ない理由 (上層部からの抵抗、新しいテクノロジの採用など) がない限り、grails を使用できない、または使用できない理由はわかりません。少なくとも試しました。

デバッグに関する懸念に答えるのは、それほど難しいことではありません。Netbeans IDE を使用すれば、デバッグは簡単です。ここで、もう 1 つ言及する必要があります。すべての IDE でいくつかの実験を行った結果、Netbeans がこの作業に最も適していることがわかりました。コード補完、構文の強調表示、デバッグなどのサポートが向上しています。私の意見では、STS は十分ではありません。

于 2010-07-30T21:50:58.503 に答える
1

Eclipseプラグインは以前よりも優れていて、目的に適合していますか？

昨年は間違いなく大幅に改善されました。12月にロンドンで開催されたGroovy＆GrailsExchangeに参加しました。記録されたEclipse/SpringSource STSでのGroovy＆Grailsの統合に関して素晴らしい話がありました。ビデオを参照してください。

私の観点からすると、Eclipseは多くの地位を獲得しました。現在、IntelliJは少し進んでいるようですが、今後数か月以内に変更される可能性があります。

于 2010-01-13T10:02:59.210 に答える
1

個人的には、RoRを学び、いくつかのホームプロジェクトで使用しましたが、Grailsに切り替えました。これは、主にJVMで実行されるため、Javaパフォーマンス/プロファイリングプログラムの過多を利用したいと考えています。問題になる前のコードのボトルネック。

一般的に、RoRとGrailsで使用されるIDEの品質にあまり違いはありません。公平を期すために、私はLinuxでプログラミングしており、RoR開発用にTextMateを試したことはありません。RoRを使用していたときは、Netbeansを使用していました。

現在、私はSTSを使用してプログラミングを行っており、Grailsで使用するのが楽しいと感じていますが、メソッドの検出/完了がはるかにうまく機能する可能性があることはまだわかっています。

于 2011-03-30T02:03:48.953 に答える
1

eclipse プラグインに関しては、まだ準備中ですが、Spring Source (SpringSource Tool Suite) の eclipse バージョンを使用できます。

http://www.springsource.com/products/sts

以前のプラグインのバージョンに比べてかなりまともです。Spring Source は grails と groovy を担当する会社を買収したため、STS はすぐに良くなることが期待できます。

于 2010-01-17T19:37:33.140 に答える
0

私はノーと言うでしょう。特に何かのプロトタイプを作成したいだけの場合は、ほとんどの用途でまだ肥大化しています。Webアプリケーションを作成するために、そのすべてのコード、grailsにバンドルされているすべての依存関係は必要ありません。Webアプリケーションを出すたびに春は必要ありません。依存関係に満ちた世界全体をスタックに追加する前に、達成しようとしていることを確認してください。アプリケーションが何で構成されているかを知ることが重要だと思います。

ルビーのシナトラのように、はるかに軽いラットパックのようなものを見ることをお勧めします。

于 2012-10-10T21:08:56.690 に答える
0

私はフルタイムの Java 開発者ですが、趣味のプロジェクトで Rails を使用しています。私たちは 1 年前に職場でプロジェクトの grails を評価しました。grails を使った経験に少しがっかりしたので、Rails の調査を始めました。両方を使用した私の印象では、Groovy は言語として Ruby にそれほど遅れをとっていませんが、Rails は Grails よりも大幅に改善されたエクスペリエンスを提供します。簡単に言えば、特に利用可能な優れた gem の数を考慮に入れると、レールははるかに多くの現実世界の問題を解決するように見えます。検索、バージョニング、RSS、クラッド以外のアプリ、クラウド サービスとの統合などを考えています。grails は Rails 1.x のレベルにあるという印象を受けます。今月末までにRails 3がリリースされているはずです。私達' 実際、仕事でレールを使用する方向に進むことにしました。最終的に、grails は Java 開発者にとっては理解しやすいものですが、最終的には、より幅広いプロジェクト要件をカバーするための改良が欠けています。

于 2010-01-13T09:48:49.987 に答える
0

2013年末の私の経験から。

長所

  • プラグインをほとんど使用せず、Grails の no-s と never-s のセットを制限すると、非常にスムーズな開発体験になります。

短所

  • 更新 (F5) は常に問題です。そしてこれが一番厄介です。何らかの理由で、3 回目から 4 回目の更新ごとにサーバーを再起動する必要がありました。question1、question2というよく知られた再起動バグがありますが、めったに発生しません。
  • 言語レベルのバグ。静的内部クラスを使用していたときは、変更時に常にサーバーを再起動する必要がありました。ビルドには問題ないが、言語の使用は私には限られている
  • 起動時間、ビルド時間、アプリケーション サイズ (小さなアプリの場合は 70 MB)、メモリ使用量
  • リモート デバッグのみ、IDE デバッグは非常に不安定
于 2013-09-26T06:50:16.153 に答える