2

私は最近、シングルトンはロギングと構成にのみ適しているという私の見解に異議を唱えました。また、依存性注入を使用すると、サービスやリポジトリをシングルトンとして使用できない理由がわかりません。

DI はインターフェイスを介してシングルトン インスタンスを挿入するため、カップリングはありません。唯一の合理的な議論は、サービスが状態を共有している可能性があるということですが、考えてみれば、サービスは状態を共有しない独立したユニットであるべきです。はい、リポジトリに注入されますが、リポジトリ インスタンスを作成してサービスに渡す方法は 1 つしかありません。リポジトリは共有状態を持つべきではないため、シングルトンにできない理由はわかりません。

たとえば、単純なサービス クラスは次のようになります。

public class GraphicService : IGraphicService
{
    private IGraphicRepository _rep;
    public GraphicService(IGraphicRepository rep)
    {
       _rep = rep;
    }

    public void CreateGraphic() 
    {
      ...
      _rep.SaveGraphic(graphic):
    }
}

変更されない、または独自の状態を持つリポジトリを除いて、状態はサービスで共有されません。

問題は、サービスとリポジトリに状態がなく、インターフェイス、構成、または同じ方法でインスタンス化されたものを介してのみ渡される場合、それらを singleton として持たないのはなぜですか?

4

2 に答える 2

3

シングルトン パターン、つまりクラスの静的プロパティを使用している場合は、密結合の問題があります。

クラスのインスタンスが 1 つだけ必要で、その有効期間を制御するために DI コンテナーを使用している場合、欠点がないため問題ありません。アプリはシングルトンが配置されていることを認識せず、DI コンテナーのみがそれを認識します。

要するに、クラスの単一インスタンスは有効なコーディング要件であり、唯一の問題はそれをどのように実装するかです。Di Container が最良のアプローチです。Singleton パターンは、保守性とテストをあまり気にしない、簡単で汚いアプリ向けです。

于 2013-10-13T14:18:20.140 に答える