私はORMが初めてで、休止状態です。私のアプリケーションは複雑なデザインパターンです。ビルダー、流暢なインターフェース。また、これらのオブジェクトは、illieagel オブジェクトの作成中にも例外をスローします。orm マッピングを使用してデータベースにアクセスします。これらの ORM エンティティを複雑なオブジェクトに変換し、その逆も行います。それは良い考えですか、それとも他の代替案ですか。
2 に答える
原則として、本当に必要なときにビジネス オブジェクトを作成する必要があります (この場合は既に存在します)。したがって、アプリケーションがこれらの複雑なオブジェクトを必要とする場合は問題ありません (ただし、データベースと Hibernate オブジェクトに変更を加えると、一連のオブジェクトを変更する必要があるため、維持するのが難しいことに注意してください)。これらの複雑なオブジェクトを取り除くことができれば、アプリケーション全体で Hibernate の切り離されたエンティティを単純な DTO として使用でき、オブジェクトの 2 つのセットを維持するのに苦労することはありません。一方、ビジネス オブジェクトを使用すると、Web レイヤー (または他のレイヤー) を Hibernate とそのエンティティから独立させることができるため、将来何らかの形で Hibernate を使用しないことにした場合でも、作業が楽になります。私の経験から、
リッチ/コンプレックスと ORM ベースの 2 種類のエンティティが必要であるという要件はありますか?
ORM をドメイン駆動設計と共に使用したところ、問題なく動作しました。リッチエンティティ (および値オブジェクト) をサービスから切り離し、それらのエンティティを集計から下位に永続化しました。
ハイバネート マッピングを使用する場合は、これらのエンティティを少し変更する必要がありますが、DDD モデルを壊すようなものは見つかりませんでした。たとえば、パラメーターなしのコンストラクターはプライベートにすることができます。
流暢/xml マッピングを使用したため、モデルは永続層から完全に分離されました。永続性無視という用語を参照してください。