Grailsフレームワークの落とし穴
Grailsフレームワークを使用する上での最大の問題/落とし穴は何ですか？私は現在フレームワークを学習していますが、それは本当に好きですが、それを使用するときに発生する可能性のある主要な問題とそれらを回避する方法を知る必要があります。
IMO、Grailsの最も弱い部分は、データモデルの移行機能がないことです（ala Rails ActiveRecordの移行）。さまざまなレベルの品質のサードパーティプラグインがいくつかありましたが、公式のものはありません。
ただし、Liquibaseが拡張されてデータベース移行プラグインに変わったことを発見しました。これは有望に見えます。 http://www.grails.org/plugin/database-migration
プラス面として、私がGrailsを使用したすべてのこと（単純から中程度の複雑なWebアプリ）については、ほとんど素晴らしかったです。 Java/Hibernate/Spring/Spring MVCスタックを使用すると、開発の生産性が約2倍から3倍向上します。
統合テストの実行は、Grails環境の読み込みに時間がかかり、テストの実行に必要な時間はごくわずかであるため、遅くなりました。これにより、dbに書き込むコードを開発する際の所要時間が増加します。もう1つの問題は、カレブの回答（データの移行について）ですでに言及されています。また、行き詰まっているときはいつでも、HibernateやSpringで利用できるヘルプと比較して、サポートを受けることができるフォーラムの数が限られていることがわかりました。
フレームワークを使用する際の現在の落とし穴は、gradleビルドシステムへの現在の不十分な統合です。現在プラグインを使用してこれを実現していますが、プラグイン自体が新しいバージョンのGrailsで壊れています（私が最近使用して修正しようとしたため）。彼らは、gradleを（ガントではなく）ビルドシステムの一部にすることで、この問題を将来のバージョンで修正する予定ですが、簡単に統合できるビルドシステムがないことが問題です。ただし、この落とし穴は将来なくなるでしょう。
もう1つの落とし穴は、言語の動的な性質です。あなたは本当にすべてのテストを書かなければなりません。コードのエラーのほとんどは実行時に検出されます。これは、実際にはプログラムについての別の考え方です。コンパイラーに依存してミスを見つけても、このフレームワークでは起こりません。私はそれが悪いと言っているのではなく、ただ違うだけです（そして、あなたがそれに慣れていない場合の落とし穴）。
私は、Grails/Groovyのコンセプト全体が好きですが、個人的には、Grailsよりも単純なGroovyを使用していますが、どちらもすばらしいと思います。
（私の個人的な経験では）唯一の欠点は貧弱ですIDEサポート。SpringSourceは優れたEclipseビルドを備えており、Grailsの強力なサポーターであるので、これがgo。groovyプラグインのインストールは難しく、コード補完は不安定です（常に動的言語の問題ですが、60のメソッドを選択してもそれほど役に立ちません）。groovyの内部コードをステップ実行する必要があるため、デバッグは面倒です。そして、最新リリースでgroovyプラグインをインストールすると、Javaデバッガーが壊れます！
現在、抽象クラスをサポートしています。たとえば、実装のリストをコマンドオブジェクトの単一のList<T>にバインドすることはできません。確かに、私は魔法のように他のすべてのものをバインドすることに慣れているので、これは主に迷惑です！ ：D
一般に、それはまだ「グリーン」のようなものです。最終的には、奇妙な小さな制限やバグに遭遇します。しかし、それは数年で本当に長い道のりを歩んでいます。