現在、Hibernate Tools 3.1 を使用しています。命名規則と DAO テンプレートをカスタマイズしました。データベース (SQL Server 2005) は初期の開発段階にあり、私はマッピング、エンティティ、DAO、構成などの再構築を担当しています。テーブルをリバース エンジニアリングする必要があるたびに、マッピング (*.hbm.xml ファイル) で行ったすべてのカスタマイズが失われます (たとえば、ID列の調整、 equalsおよびtoStringで使用されるフィールドの選択など) 。diff XML をファイルに書き込み、それを生成されたマッピングに「マージ」することを検討していました (関連する質問を参照) が、疑問に思っていました...これらの迷惑で避けられない重要な問題に対処するためのベストプラクティス/ツールはありますか?タスク？
Manrico Corazzi
質問する
665 次
2 に答える
2
継続的なリバース エンジニアリングに反対することを強くお勧めします。リバース エンジニアリングは 1 回限りの優れた作業ですが、変更は hbm とデータベースの両方に対する変更として管理する必要があります。
マイグレーションを使用してデータベースの変更を管理し、関連する変更を hbm に含めます。Hibernate にある場合 (あると思います)、hbm の代わりに注釈を調べると、メンテナンスがかなり簡単になります。
于 2008-09-17T07:21:11.030 に答える
1
2年半遅れですが、反対意見を述べさせていただきます。hibernate.reveng.xml ファイルまたはカスタム ReverseEngineeringStrategy を使用して、マッピング ファイルに必要なカスタマイズを行うことができるはずです。クラス自体については、常に基本クラスを生成し、カスタム コードを含むクラスで拡張する必要があります。
たとえば、com.company.vo.generated.CustomerGenerated を生成し、com.company.vo.custom.Customer で拡張します。コード生成は、生成されたパッケージ内のすべてのクラスを上書きする必要がありますが、カスタム パッケージ内では決して上書きしないでください (ただし、必要に応じてカスタム ディレクトリに空白をコピー アンド ペーストできるように、Hibernate Tools でこれらのカスタム クラスをターゲット ディレクトリに生成することができます)。このようにして、カスタム クラスの equals や toString などのメソッドをオーバーライドし、再生成時に変更を失わないようにすることができます。また、ベスト プラクティスは、生成されたコードを SCM にチェックインしないことです。
このサイトには、Maven、Hibernate3 プラグイン、およびビルド ヘルパー プラグインを使用してこれを実現する方法の素晴らしい例がいくつかあります。これらのほとんどには、Pascal Thivent による非常に役立つ回答があります。この方法は私にとってはうまく機能しています。学習曲線は少しありますが、単一の Maven コマンドでデータベースの変更をアプリに伝達できるのは素晴らしいことです。
于 2011-03-22T08:52:04.587 に答える