質問
Java \ Spring \ Hibernateアプリケーションがあります-基本的にHibernate POJOであるドメインクラスを備えています
Grailsでうまく記述できると思う機能があります。
メインのJavaアプリで作成したドメインクラスを再利用したい
これを行う最良の方法は何ですか?
Javaクラスを拡張する新しいドメインクラスを作成する必要がありますか?これはベタベタします または、Javaドメインクラスからコントローラーを「生成」できますか?
Grails \ GroovyでJavaドメインオブジェクトを再利用する際のベストプラクティスは何ですか grails \ groovyにいくつかの作品を書いている人が必ずいるはずです
このような統合について説明しているチュートリアルを知っているなら、それは素晴らしいことです!!!
PS:私はgrails-groovyの初心者なので、明らかな見落としがあるかもしれません。ありがとう!!!
解決
GroovyだけでなくGrailsを本当に使いたい/必要ですか?
Grailsは、既存のWebアプリにパーツを追加するために使用できるものではありません。 「設定より規約」全体アプローチとは、Grailsのルールに従ってプレイする必要があることを意味します。そうでなければ、使用する意味がありません。そして、それらのルールの1つは、ドメインオブジェクトがGroovyクラスであり、「強化」されていることです。 Grailsランタイムによって。
既存のJavaクラスを拡張することは可能かもしれませんが、私はそれには賭けません。そして、既存のアプリのSpringとHibernateのすべての部分を破棄するか、少なくとも費やす必要があります。 Grailsで機能させるための多大な努力。フレームワークから利益を得るのではなく、戦うことになります。
IMOには2つのオプションがあります:
- 既存のコードを可能な限り再利用しながら、Grailsでアプリをゼロから書き直します。
- アプリをそのままにして、Grailsを使用せずにGroovyに新しいものを追加します。
あなたの状況では後者の方がおそらく良いでしょう。 Grailsは、新しいWebアプリを非常に迅速に作成することを目的としています。既存のアプリにアイテムを追加することは、それが何のために作られたかということではありません。
編集: コメントの明確化について:別のアプリで使用されるデータのデータエントリ/メンテナンスフロントエンドを基本的に記述し、それらの間の唯一の通信チャネルとしてDBを使用することを計画している場合、実際にはGrailsで非常にうまく機能する可能性があります;ドメインクラスから独自のDBスキーマを作成するのではなく、既存のDBスキーマを使用するように確実に構成できます(後者は作業が少なくなります)。
他のヒント
GroovyとGrailsが既存のJavaコードとの統合に優れていることを知っているので、私はあなたのオプションについてMichaelよりも少し楽観的かもしれません。
最初のことは、すでにSpringとHibernateを使用していることです。ドメインクラスは既にPOJOであるため、簡単に統合できるはずです。あなたが持っているかもしれないSpring Beanは、通常通りにXMLファイルで指定することができます( grails-app / conf / spring / resources.xml
で)、または GrailsのSpring Beanビルダー機能。その後、任意のコントローラー、ビュー、サービスなどで名前でアクセスし、通常どおり操作できます。
ここに、ドメインクラスとデータベーススキーマを統合するためのオプションを示します。
-
GORMをバイパスし、既に実行しているとおりにドメインオブジェクトをロード/保存します。
GrailsはGORMの使用を強制するものではないため、これは非常に簡単です。Javaコードの
.jar
を作成し(まだ持っていない場合)、Grailsアプリのlib
ディレクトリ。 JavaプロジェクトがMaven化されている場合はさらに簡単です。Grails1.1はMavenと連携するため、Grailsアプリ用のpom.xml
を作成し、他の場合と同様にJavaプロジェクトを依存関係として追加できます。 (Java)プロジェクト。どちらの方法でも、クラス(およびサポートするクラス)を
インポート
して、通常どおりに進めることができます。 GroovyはJavaと緊密に統合されているため、Javaプロジェクトの場合とまったく同じように、オブジェクトの作成、データベースからのロード、変更、保存、検証などを行うことができます。この方法でGORMのすべての便利さを手に入れることはできませんが、既に理にかなっている方法でオブジェクトを操作するという利点があります(Groovyのおかげでコードが少し少なくなる場合を除く)。最初にこのオプションを試して何かを機能させてから、その時点で意味があると思われる場合は、後で他のオプションのいずれかを検討することができます。このオプションを試す場合のヒント:実際の永続化コードをGrailsサービス(
StorageService
)に抽象化し、コントローラーが永続化を直接処理するのではなく、そのメソッドを呼び出すようにします。この方法で、必要に応じてサービスを将来の別のものに置き換えることができ、同じインターフェースを維持している限り、コントローラーは影響を受けません。 -
新しいGrailsドメインクラスを既存のJavaクラスのサブクラスとして作成します。
クラスがすでに適切なBeanとして記述されている場合、つまり、すべてのプロパティに対してgetter / setterメソッドを使用している場合、これは非常に簡単です。 Grailsは、これらの継承されたプロパティーを、より単純なGroovyスタイルで作成した場合と同じように表示します。単純な検証チェック(null、空白ではないなど)を使用するか、POJOスーパークラスの既存のメソッドを呼び出すなど、より複雑な処理を行うクロージャーを使用して、各プロパティの検証方法を指定できます。
ほぼ確実に、 GORMマッピングDSL を使用してマッピングを調整する必要があります。既存のデータベーススキーマの現実に合わせて。関係はそれがトリッキーになるかもしれない場所になります。たとえば、GORMが結合テーブルを期待する他のソリューションがあるかもしれませんが、これらのような違いを回避する方法さえあるかもしれません。 GORMとそのマッピングDSLについてできる限り学習し、いくつかのクラスを試して、これが実行可能なオプションかどうかを確認することをお勧めします。
-
Grailsは既存のPOJOとHibernateマッピングを直接使用します。
自分で試したことはありませんが、Grailsの Hibernate Integrationページによると、可能に:" Grailsでは、ドメインを作成することもできます