[解決済み] IoCコンテナを使って、エンティティ/ビジネスオブジェクトの依存関係を解決しませんか？

質問

DI のコンセプトは理解していますが、さまざまな IoC コンテナで何ができるかを学んでいるところです。 多くの人は、ステートレス サービスの配線に IoC コンテナを使用することを勧めているようですが、エンティティのようなステートフル オブジェクトに使用する場合はどうでしょうか。

それが正しいか間違っているかは別として、たとえその動作が外部のクラスを必要とするとしても、私は通常、エンティティに動作を詰め込みます。 例を挙げます。

public class Order : IOrder
{

    private string _ShipAddress;
    private IShipQuoter _ShipQuoter;

    public Order(IOrderData OrderData, IShipQuoter ShipQuoter)
    {
        // OrderData comes from a repository and has the data needed 
        // to construct order
        _ShipAddress = OrderData.ShipAddress;  // etc.
        _ShipQuoter = ShipQuoter;

    }

    private decimal GetShippingRate()
    {
        return _ShipQuoter.GetRate(this);
    }
}

見ての通り、依存関係はコンストラクタ・インジェクションされています。では、いくつか質問です。

1. エンティティを ShipQuoter のような外部のクラスに依存させることは、悪い習慣と考えられていますか? 私が定義を正しく理解しているならば、これらの依存関係を排除することは、貧弱なドメインに向かって私を導くように思えます。

2. これらの依存関係を解決し、必要なときにエンティティを構築するために IoC コンテナを使用することはバッドプラクティスでしょうか。 これを行うことは可能でしょうか？

どんな洞察でもありがとうございます。

どのように解決するのですか？

最初の質問は、答えるのが最も難しいものです。エンティティを外部のクラスに依存させるのは悪い習慣なのでしょうか？確かに、最も一般的なことではありません。

例えば、EntityにRepositoryを注入する場合、事実上、Entityの実装は アクティブレコードパターン . このパターンが便利で好きな人もいれば、（私のように）コードの臭いやアンチパターンと考える人もいます。 単一責任の原則 (SRP) に違反しているからです。

Entity に他の依存性を注入すると、同じ方向（SRP から離れる方向）に引っ張られると主張することができます。一方、これを行わない場合、引き寄せられる方向が 貧弱なドメインモデル .

私は長い間、Greg Youngの(放棄された) DDDD に関する論文 で、なぜ ステレオタイプのN層/Nレイヤーアーキテクチャは常にCRUD的である。 (したがって、むしろ貧弱) である理由を説明しています。

ドメインオブジェクトのモデリングに焦点を移すと コマンドとイベント としてモデル化することで、適切なオブジェクト指向のドメインモデルを構築することができるようです。

2番目の質問は答えるのが簡単です。あなたは常に 抽象ファクトリーを使用して、実行時にインスタンスを作成することができます。 . Castle Windsorでは、型付きファクトリー機能を使うこともでき、手動でファクトリーを実装する負担を軽減することができます。