私の考えでは、ここでは逆の構造が必要なように感じます。
エンティティは、サービスに依存して、さまざまなプロパティを設定しています。これはビルダーに任せるべきですよね？(それがオブジェクトの構築です) レガシ コードを調べて、いくつかの一般的なリファクタリングを実行しています。
本質的に、エンティティはかなり愚かである必要があります.処理が混在しているように見えます.
1982 次
1 に答える
3
ドメインエンティティにサービスを注入することは良い考えではないかもしれませんが、あなたが考える理由からではないかもしれません.
本質的に、エンティティはかなり愚かである必要があります.処理が混在しているように見えます.
これは物議を醸す問題ですが、ダム ドメイン エンティティはアンチパターン ( Anemic Domain Model ) であり、プログラミングのオブジェクト指向スタイルに反すると多くの人が信じています。エンティティは、データを含むだけでなく、動作もカプセル化する必要があります。
問題は、ドメイン オブジェクトの凝集度が低下する前に、どれだけの動作を追加できるかということです。あなたの例では、サービスに依存してさまざまなプロパティを設定することは、ドメイン オブジェクトの責任 (凝集性) とそうでないものの間の典型的な境界例です。さらに、プロパティがデータベースから明示的にロードされている場合、これは永続性無視の原則に違反している可能性があります。
これらのプロパティをオブジェクトの誕生からすぐに初期化する必要があることが判明した場合、特に構築ロジックが複雑な場合は、ファクトリまたはビルダーがそのデータをフェッチしてエンティティを組み立てるのに適した場所になる可能性があることに同意します。 .
しかし、通常、このようなメカニズムは遅延読み込みを提供するためにあります。つまり、オンデマンドでジャスト イン タイムにプロパティを設定します。これにより、データベースから潜在的に大きなデータを取得するなどのコストのかかる操作を延期でき、大きなオブジェクト グラフが最初からメモリに読み込まれることを回避できます。
個人的には、遅延読み込みの目的で構築時にサービスがエンティティに挿入されるのを見て気分を害することはありませんが、悪い習慣だと考える人もいます:こちらとこちらを参照してください。よりクリーンでテストしやすいエンティティには、メソッド インジェクションまたはデリゲート インジェクションを使用することをお勧めします。
于 2012-07-26T12:30:10.767 に答える