Grailsには価値がありますか？
これは半分の暴言、半分の質問です。
Grailsを使用する価値はありますか？比較的単純なデータベース駆動型のWebアプリケーションを開発しようとしています。私の専門はJavaなので、当然Grailsは良い選択のように思えました。最初は、Spring、JPA、Hibernateを使用することを考えましたが、以前はそれを使用していたため、あらゆる種類の退屈な構成とコーディング作業に遭遇しました。 Grailsは、これを解決していると宣伝しています。
Grailsに対する私の最大の不満は、機能しない小さなことのすべてです。私が意味するのは、直観的に考えるとうまくいかないということです。エッジの周りは非常に粗いです。私は常に問題に直面しています。 Grailsの理解が足りないこともあれば、正当なGrailsのバグを発見したこともあります。
1つの大きな問題は、Eclipseの適切な統合の欠如です。 GroovyとGrailsのプラグインがありますが、構文の強調表示以外のことはあまりしません。 JavaからGroovyを呼び出すと、その逆は configure に非常に苦痛です。IDEサポートは大きな問題です。
何が起こるかは、自分のWebアプリケーションを開発しようと座っていることです。 1日の終わりに、Grails関連の問題のデバッグに1日の約85％を費やしたことに気付きます。 Eclipseの問題でない場合は、 積極的な読み込み 、 ビューでのフェッチ 、 1対多の関係 、 空のファイルの奇妙なバグの動作 、 奇妙なプロパティ/ゲッターのバグ -それはどんどん続きます。これは、私が今日遭遇した問題のほんの一例です。 Grailsとの最後の座り心地は、さまざまな問題をもたらしました。
価値があるのかと思うこともあります。他の人がこれを経験したことがあるのか興味があります。実際にGrailsを使用してWebアプリケーションを生産的にクランクアウトする人はいますか？検討すべき迅速なWeb開発のためのその他のフレームワークはありますか？
0.6BからGrailsを学んだ、経験豊かなシニアJava開発者の12人のチームがあり、私たちはまだGrailsに基づいたプロジェクトに取り組んでいます。 Javaに喜んで戻ることはありません。Grailsアプリを使ってどこかにすばやくアクセスする方法の裏側を破ったことで、私たちは皆安心しています。
それは苦労であり、簡単ではなく、フラストレーションがありました。
それにも関わらず、私たちは継続的な努力を払って非常に迅速に何かを提供しました。
Javaが得意で、Grailsプロジェクトの深く複雑な呪文に飛び込もうとする開発者のインスタンスをいくつか聞いたことがあります。すべてのJavaを避け、純粋なGrailsとGroovyに移行しました。私たちはシンプルに始め、可能な限り管理しやすく、実際的に複雑さを作り上げました。私たちはあえて最深部に飛び込むことはせず、私たちのJava知識で十分だと思います。
最終的に、巨大で複雑なものを作成しましたが、これは途方もなく機能し、純粋なJava/Spring/Hibernateバージョンを書くよりもはるかに高速でした。それはきちんとしたIDEサポートがなく、バグに関しては今日よりもはるかに悪い状況です。
Eclipseのサポートに関しては、Grails/Groovyで使用する唯一の本当のIDEはIntellijです。Eclipseのサポートはかなり遅れています。しかし、Groovyのサポートは他のすべてを吹き飛ばします。
はい、GrailsはおそらくSpringに比べて未熟です。または休止状態。そして、私は彼らの存在の最初の1。5年に彼らが同様に問題に満ちていることを賭けます。
それはそのままで、あなたに責任を負わせ、複雑さを絶対最小限に抑え、慎重に最初にテストし、複雑さを徐々に慎重に構築することに注意してください。
スタックにSpring/Hibernateを含めると、Javaを使用した高速なコードソリューションはありません。 Grailsが体現する複雑さは、Spring/Hibernate自身の複雑さを反映しています。純粋なJavaで時間を費やしたほうがいいと思うなら、私はそうは言いません。私はまだWTFを持っていますが、今では急な学習曲線が私の後ろにあります。
私は2つの理由からgrailsアプリケーションを書くことをとても楽しんでいます。
- Javaを使用する必要はありません
- Javaを使用できます
聖杯に精通した後、人は物事を非常に迅速かつエレガントに終わらせると思います。
プラス面はこれで終わりです。マイナス面はパフォーマンスです。これは、展開とテスト駆動開発という2つの側面にぶつかります。
単一の（レンタル）サーバーで3つ以上のgrailsアプリケーションを実行することができませんでした。メモリとパフォーマンスの制限にすぐに到達したためです。含まれているフレームワークが多すぎます。
さらに、grailsのテストランナーはその名前に値しません。単体テストを実行するときは、10〜20秒ではなく、すぐに実行する必要があります。ですから、ビジネスロジックをプレーンJavaで書くのは、ずっと速くテストできるからです。しかし、これはIDE（Eclipse）へのより良い統合で対処できると思います。
GrailsへのSpringのサポートは大きな後押しになると思います。誰かがそれをWeb上のCRUDを越えて移動できるなら、それはそれらの人たちです。
私はまた、それが臨界質量に達していると思います。 2009年に市場に出回るいくつかの新しい本があります。それらは採用率を助けると思います。
私は元のポスターの感情に完全に同意します。
私たちはJava + Springショップであり、Grailsを試してみる機会を得ました。最初に非常に小さなテストアプリケーションを作成しました。ここでの問題は、GroovyとGrailsの知識不足によるものでした。
この成功（自信の向上）に続いて、私たちはわずかに大きなプロジェクトを試みることにしました。これははるかに痛みを伴う経験でした。他の人が述べたように、私たちは表面上ですぐには明らかにならないあらゆる種類のバグや問題を発見しました。アプリの再起動サイクルは非常に痛みを伴い、テストのカバレッジが非常に良好でない限り、何らかのリファクタリングを行うのは悪夢です。
本当にイライラするのは、単一のエラーメッセージなしでコードが失敗することです！それはうまくいかず、なぜあなたは知らないのですか？
いくつか例を挙げると、JMS、Quartz、およびRemotingのプラグインの使いやすさが気に入っています。多くの退屈なXMLを廃止します。
いくつかの問題もありましたが、そのシンプルさでGORMが好きです。
Groovyの緩やかに型付けされた性質と、多数のエラーをキャッチするためだけにアプリケーションを実行する必要があるという事実は気に入らず、PHPまたはRails。
最終的には、Grailsを使用して管理可能なソフトウェアの複雑な部分を作成できるかどうかを確認しています...
本番環境に移行するGrailsアプリケーションがあります。
Webレイヤーでgrails +を使用しています+ Javaサービスレイヤーでhibernateとspringを使用します。Webはgrailsであり、ロジックはJavaで実装されます。Javaで通常行われるように、異なる層間のデータを表すBeanオブジェクトを使用します。
これは非常にうまく機能し、Beanオブジェクトとデータベース構造がすでに存在するため、このケースに最適なソリューションでした。私たちの経験から、grailsはWebプレゼンテーションレイヤーとして大きな価値があると思いますが、Javaを使用して、ビジネスルールを記述し、アプリケーションデータを永続化します。 、すべてのgrails-Java統合は非常に簡単です。
Eclipseを使用してgrailsアプリケーションを開発しますが、統合が不十分です。ただし、他の開発者からの提案として、コマンドラインからgrailsアプリケーションを実行し、Eclipseのみを使用してソースファイルを保存します。アプリケーションはオンザフライで更新されるため、非常にうまく機能します。
私はまだプレゼンテーション層以外の場所で杯を使うことに不安を感じています。
私は完全にあなたと一緒です！ Grailsはまだエッジの周りがとても荒いので、Railsと比較するのはほとんど冗談です。少なくともエラー報告が少し改善された場合。しかし、それはおそらく、それが内部で使用する膨大な量のライブラリーによるものだと思います。 1つの単語：stacktrace！私はmodel-> dbアプローチの大ファンでもありません（Railsにはdb-> modelがあります）。足場にも改善の余地が多くあります。その場合、「再起動は不要」も広告どおりに機能しません。 （さらに悪いことはわかりません-常に再起動する必要があるか、再起動すると消える奇妙な動作を見つけることがあります）そして、GORMを開始しないでください。 （単純なSQLであったはずの方法を見つけるのに数時間かかると、このORM全体が本当に時間を節約するかどうか疑問に思うようになります）単純である限り。
つまり、Javaの世界から来たとき、それはフレームワークのより良い選択の1つです。（それ自体がWebフレームワークと呼ばれる無用のくだらないものがたくさんあります）...他の複雑なものの上に構築しないでください。
とにかく-これらのものがソートされることを期待しましょう。現時点では playframework.org に潜んでいますが、これも非常に滑らかで有望です。
Ruby on Rails Java世界で何かをするよりも、Rails $ === m全体的に、Grails is 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が実際にメリットをもたらすとは思いません。たぶんsans IDE=
だから、そう、Grailsには価値があると思う。彼らは物事をできる限り早く機能させるために素晴らしい仕事をしてきました。GrailsとGroovyのチームは両方とも本当に献身的です。
彼らがEclipseプラグインを完成させるとき、それは価値があります。早ければ早いほどいい。グルーヴィーを上司に売ろうとしても、それが起こるまで簡単ではありません。
Grailsの最大の利点は、データベースを気にする必要がないことです。スキーマは自動的に作成/更新され、永続化は主に行われます（SQLクエリを記述する必要はありません）。これは大きな安心です。もう1つ良い点は、コントローラーとビューのテンプレートを決定したら、新しいドメインオブジェクトの追加が非常に高速になることです。私はあなたが少なくともあなたの見解に対して継続的な変更を行い、それらを既存のものに適合させることを疑います。
IDE-IntelliJが最適なオプションのようですが、Netbeans 6.5を使用してうれしいです。他のすべての開発にMyEclipseを使用していますが、NetbeansのGrailsサポートが向上しています。
私は新しいプロジェクトでgrailsを使い始めたばかりです... xmlファイルを記述する必要はありませんが、SpringとHibernateのパワーはまだ素晴らしいです。
IDEにIntellijIDEAを使用しますが、実際にIDEを介してGrailsを発見しました（ただし、偏っているかもしれませんが、私は嫌い Eclipse）。
Grailsを使い始める前は、Eclipseユーザーでした。それを削減するつもりはなかったことがすぐに明らかになりました。そこで、IntellijとNetBeansを試しました。当時、IntellijはGroovyとGrailsに関してはより優れていました。ただし、NetBeansは無料であったため、私にとっては十分なものでした。それ以来、3つすべてに新しいバージョンまたは新しいプラグインがリリースされました。 Intellijのコストのため、私はまだNetBeansを使用しています。 Spring SourceによるG2Oneの買収により、EclipseでのGroovyおよびGrailsのサポートが期待されています。これは、採用を増やすために必要です。
Grailsを新しいプロジェクトに使用するのは素晴らしいことです。非常に多くのエンタープライズJava手荷物はもう必要ありません。フレームワークの長所と短所がどこにあるかを理解するまで効率的に利用するのが難しいため、何かを移植しようとするのは難しいでしょう。 Grails 1.1ではJSPのサポートが容易になると約束されていますが、新しいフレームワークを手探りしながらベータ版を使用するのが良い考えかどうかはわかりませんが、テストでは新しいバージョンのメジャーリビジョンも行われています。 1.1のリリースはもうすぐですので、時間がかかる場合があります。
Grailsを別のIDEで試してみる機会がある場合は、プロジェクトをゼロから開始するときに、別の観点から見ると思います。
まったく。非常に多くのJavaフレームワークがあるため、初心者にとっては水準が非常に高く設定されており、Grailsがこのような混雑した空間で上に上がることができた証です。
まだ鋭いエッジがいくつかありますが、それらはマットになる前の時間の問題であり、基礎となるプロジェクトは非常に価値があります。
Grailsは、最初の初期化で作成された多数のファイルと必要なリソースに基づいて、アプリケーションのタイプによっては大きくなる場合があります。シンプルなものを探しているなら、Grailsはあなたが探しているものではないかもしれません。シンプルで機能するものを探しているなら、これまでのところDjangoはあなたの仕事をうまくやることができます。 そのチュートリアル 。ここから、アプリはニーズと要件の拡大に応じて（比較的）簡単に拡張できます。
彼らがGrailsをあなたが知っているように正しくできるかどうかはわかりません。そして、私は最終的にすべての詳細（小さなものと大きなもの）に対処することを意味します。その背後に実際の開発チーム（2人以上を意味する）があるかどうかさえわかりません。
Grailsプロジェクトの機能を反復して何かを改善しようとするたびに、それは同じワークフローです：すべてがバラバラになり、それが100の「グーグル」テストサイクルであり、あなたができない理由を見つけますあなたが望むものとあなたは何か他のことをします。
結局、実行するものに触れたくないので、あなたはイライラします。そしてうまくいかないものは、あなたはそれらを落とす！
JRubyを介したRailsへの切り替えを検討しています。これは、両方の長所です。アクティブで大規模なコミュニティを持つ有能なWebフレームワーク、専任の開発者チーム、 SpringやHibernateのような疑わしく複雑なフレームワーク、迅速で野心的なリリースサイクルに基づくものではありません。JRubyは、率直に言って、バックパックに非常に多くのJavaアセット.
あなたの専門知識がJavaあなたが言うように。あなたは Play Framework を見る必要があります-Ruby = on Rails非常に短い開発サイクルで-Javaソースファイルを保存し、Webブラウザを更新します。他の言語を試してみたい場合は、Playフレームワークには、代わりにScalaを使用できるモジュールがあります。
Play Frameworkは理解しやすく、優れたパフォーマンスを備えているので気に入っています。必要に応じて、ORMレイヤーにJPAとHibernateを使用することもできます。