Morphia や Hibernate などの永続性フレームワークは、その魔法を実行するためにドメイン オブジェクトの注釈に依存していることを理解しています。あるレベルでは、これはドメイン レイヤーに永続性に関する懸念を持ち込むことになり、これは避けるべきことのように思えます。
これは、外部構成ファイルを使用したり、ドメイン モデルから DTO を分離したりして回避する必要があるのでしょうか。それとも、永続化レイヤーとドメイン レイヤー間のこの小さな漏れは、一般的に許容できるものと見なされるのでしょうか。
ベストアンサー1
Spring と Hibernate を使用した既存のシステムの最新の反復では、同様のことを始めました。最初に Hibernate モデルを実装したとき、サービス クラスのアプリケーション ロジックをデータ アクセス オブジェクトを介して永続ロジックから分離するように努めました。昨年、新しいシステムを構築したとき、ほとんどの永続オブジェクトをドメイン オブジェクトとして機能させました。それが適切な解決策だったからです。
しかし、私はビジネス要件の変化を考慮してこの同じシステムを再設計しており、再びそれらの懸念を分離する方向に傾いています。新しい設計を開始してまだ数日ですが、すでに、メモリ内の懸念オブジェクトを表す 1 つのオブジェクトと、その状態変更をデータベースに保存するための別の永続性ベースのオブジェクトを使用する方がよいと考えています。たとえば、永続性用の と、トランザクション間で存続するLead並列があります。ActiveLead
これが最良の方法だとはまだ確信していませんが、直感的には納得できます。私は永続性にとらわれない、いや、永続性にとらわれないコレクションをずっと欲しがっていました。無知な-- 標準の CRUD の簡略化に関係なく、データベース トランザクション全体でメモリ常駐のままになるオブジェクトのセット。ただし、最終的にはすべてのデータベース操作が CRUD として実装されることは理解しています。2 つの世界は衝突する必要があり、その秘訣はそれらを調和させることです。
ドメイン オブジェクトに対する Hibernate アノテーション? これは、実装の容易さとメンテナンスの容易さの間の優れた妥協点だと私は考えています。