Grailsはそれだけの価値がありますか？[閉まっている]

これは半分の怒り、半分の質問です。

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

Grailsに対する私の最大の不満は、機能しない小さなことすべてです。つまり、直感的に考えるとうまく機能しないということです。縁が非常に荒れています。私は常に問題にぶつかります。時々、それは私のGrails理解の欠如です—他の場合、私は正当なGrailsバグを発見しました。

大きな問題の1つは、Eclipseが適切に統合されていないことです。GroovyとGrailsのプラグインはありますが、構文の強調表示以外の機能はありません。JavaからGroovyを呼び出したり、その逆を行ったりするのは、設定が非常に困難です。IDEが適切にサポートされていないことは大きな困惑です。

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

それはそれだけの価値があるのか​​と時々思います。他の人がこれを経験したかどうか私は興味があります。実際にGrailsを使用してWebアプリケーションの生産性を高めている人はいますか？迅速にWebを開発するために考慮すべきフレームワークは他にありますか？

私たちには、Grailsを0.6Bから学んだ、経験豊富な上級Java開発者12人のチームがあり、Grailsに基づくプロジェクトにまだ取り組んでいます。私は喜んでJavaに戻るつもりはありません。私たちは、Grailsアプリを使ってどこかにすばやく到達する方法の裏をかいてしまったことで安心しています。

それは闘争であり、容易ではなく、欲求不満がありました。

それにもかかわらず、私たちの継続的な取り組みにより、非常に迅速に何かを提供しました。バグがあり、その多くに回避策があります。

Grailsプロジェクトの深く複雑な呪文に飛び込もうとする、Javaが得意な開発者のインスタンスがいくつかあると聞いています。私たちはすべてのJavaを避け、Pure-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をもう少し使い続けるつもりです。

私は2つの理由から、Grailsアプリケーションを書くのがとても楽しいです。

• Javaを使用する必要はありません
• Javaが使える

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

プラス側はこれで終わりです。マイナス面はパフォーマンスです。これは、展開とテスト駆動開発の2つの側面で私を襲います。

メモリとパフォーマンスの制限にすぐに達してしまったため、1つの（レンタルされた）サーバーで3つ以上のGrailsアプリケーションを実行できませんでした。含まれているフレームワークが多すぎます。

さらに、Grailsのテストランナーはその名前に値しません。単体テストを実行する場合、10〜20秒ではなく、すぐに実行する必要があります。それで、私はいつもプレーンジャバでビジネスロジックを書いていることに気づきました。しかし、これはIDE（eclipse）へのより良い統合で対処できると思います。

SpringがGrailsをサポートすることは大きな後押しになると思います。誰かがそれをWeb上のCRUDを超えて移動できる場合、それはそれらの人です。

私はまた、それがクリティカルマスに達しつつあると思います。2009年に市場に出回る新しい本がいくつかあります。私はそれらが採用率に役立つと思います。

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

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

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

本当にイライラするのは、単一のエラーメッセージなしでコードが失敗することです！それが機能しないだけで、なぜかわかりませんか？

JMS、Quartz、およびRemotingのプラグインの使いやすさが好きです。多くの面倒なXMLを排除します。

いくつかの問題もありましたが、私はGORMが単純であることを気に入っています。

私は、Groovyの緩やかに型付けされた性質、および多数のエラーをキャッチするためにアプリケーションを実行しなければならないという事実が好きではないことを、PHPまたはRailsに過度に思い出させます。

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

本番環境に移行しようとしているGrailsアプリケーションがあります。

私たちは、Grails +をWebレイヤーで使用し、JavaでhibernateおよびSpringをサービスレイヤーで使用しています。これは、WebがGrailsであり、ロジックがJavaで実装されている古典的な3つのレイヤー（Web、ロジック、データ）です。Javaでは通常のように、異なるレイヤー間のデータを表すBeanオブジェクトを使用します。

これは非常にうまく機能し、Beanオブジェクトとデータベース構造がすでに存在しているため、このケースでは最良のソリューションでした。私たちの経験から、GrailsはWebプレゼンテーションレイヤーとして大きな価値があると思いますが、ビジネスルールを記述し、アプリケーションデータを永続化するためにJavaを使用します-Grailsは「Java」なので、すべてのGrailsとJavaの統合はかなり優れています簡単です。

人々がここで言ったように、私たちはEclipseを使用してgrailsアプリケーションを開発していますが、統合は不十分です。しかし、他の開発者からの提案として、コマンドラインからgrailsアプリケーションを実行し、eclipseを使用してソースファイルを保存するだけです。アプリケーションはその場で更新されるため、非常にうまく機能します。

プレゼンテーションレイヤー以外の場所でGrailsを使用するのはまだ快適ではありません。

Ruby on Railsの経験は、Javaの世界での経験よりもはるかに多いので、別の視点から参入しています。全体として、Grails は、Railsよりもはるかに荒削りであり、その一部は未成熟であり、一部は隠れた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のチームはどちらも本当に本当に熱心です。

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

つまり、Javaの世界から来ている場合でも、フレームワークの優れた選択肢の1つです。（それ自体がWebフレームワークと呼ばれる、役に立たないがらくたがたくさんあります）...それは可能性を秘めています。私はそれが他の多くの複雑なものの上に構築されないことを望みます。

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

彼らがEclipseプラグインを完了すると、それは価値があります。早く言うほどいいです。グルービーを上司に売ろうとするのは、それが起こるまで簡単ではありません。

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

IDEについては、IntelliJが最良のオプションのようですが、Netbeans 6.5を使用して満足しています。私は他のすべての開発にMyEclipseを使用していますが、NetbeansのGrailsサポートが改善されました。

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

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

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

私は新しいプロジェクトでgrailsを使い始めたばかりです... xmlファイルを記述する必要はありませんが、それでもまだSpringのパワーを備えており、Hibernateは本当に素晴らしいです。

IDEにIntellijIDEAを使用しますが、実際にはIDEを介してGrailsを発見しました（偏見があるかもしれませんが、日食は嫌いです）。

完全に。多くのJavaフレームワークがあり、新規参入者にとっての水準は非常に高く設定されています。これは、Grailsがそのような混雑したスペースで上に上がることができた証です。

それはまだいくつかの鋭いエッジを持っていますが、それらがマットダウンされる前の時間の問題であり、基礎となるプロジェクトはそれだけの価値があります。

Grailsは、（最初​​の初期化で作成された多数のファイルとそれが使用するリソースに基づいて）アプリケーションのタイプによっては大きくなる場合があります。シンプルなものを探しているのなら、Grailsはあなたが探しているものではないかもしれません。あなたがシンプルでうまくいくものを探しているなら、これまでのところ私はジャンゴがあなたの仕事をうまくこなせると考えています。チュートリアルからCRUDアプリを作成するのがいかに簡単か（必要なファイル数）を見てください。ここから、ニーズや要件の拡大に応じて、アプリを（比較的）簡単に拡張できます。

彼らがGrailsを正しく理解できるようになるかどうかはわかりません。そして、正確には、すべての詳細（大小を問わず）に対処することを意味し、最終的には、もろくもろく感じます。その背後に実際の開発チーム（つまり2人以上）がいるかどうかさえわかりません。

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

結局のところ、実行するものには触れたくないのでイライラします。そして、うまくいかないものは落とす！

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

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

私はPlay Frameworkが好きです。理解しやすく、パフォーマンスが良いからです。必要に応じて、ORMレイヤーにJPAおよびHibernateを使用することもできます。