0

MyRepository別のDALプロジェクトにある以下のようなシングルトンクラスを作成しようとしています。メソッドがクラスをGetMySingleTon()返し、そのアクセスを必要とするため、循環参照の問題が発生しています。MySingleTon同じように、クラスMyRepositoryのコンストラクターでアクセスする必要があります。MySingleTon

  public class MySingleTon
  {
    static MySingleTon()
    {
      if (Instance == null)
      {
        MyRepository rep = new MyRepository();
        Instance = rep.GetMySingleTon();
      }
    }
    public static MySingleTon Instance { get; private set; }
    public string prop1 { get; set; }
    public string prop2 { get; set; }
  }

更新：私はそれを非常に間違ってやっていた。シングルトンは必要なかったと思います。これで、3番目のプロジェクトで静的プロパティを持つクラスを作成し、一度設定してどこからでもアクセスできるようになりました。そして、それは今のところ私の問題を解決しました。

皆様のご回答ありがとうございます。

4

4 に答える 4

1

リポジトリはシングルトンオブジェクトを返さないようにする必要があります。リポジトリはデータにアクセスするために使用され、シングルトンオブジェクトを返しません。リポジトリ自体がシングルトンである可能性がありますが、これはお勧めしません。また、リポジトリを使用するクラスにシングルトンを使用することもお勧めしません。あなたが持っているコードでは、リポジトリはすべて混乱している「ビジネスレイヤー」を認識する必要があるようです。関係は一方向にのみ進む必要があります。私はそれを次のように書き直します：

public class MySingleTon
{
    private MySingleTon()
    {
       // You constructor logic, maybe create a reference 
       // to your repository if you need it
    }

    private static MySingleTon _instance;
    public static MySingleTon Instance { 
       get
       {
          if(_instance == null)
             _instance = new MySingleTon();
          return _instance;
       }
    }
    public string prop1 { get; set; }
    public string prop2 { get; set; }
}

私の解決策はお勧めしませんが、問題は解決するはずです。私がお勧めするのは、設計がちょっと間違っているように見えるので、依存性の注入と制御の反転を調べることです。NInjectをご覧ください。

編集：もう1つ、シングルトンに公開されているプロパティがいくつかあるのはなぜですか？シングルトンはプロパティを公開するべきではなく、関数のみを公開する必要があり、主にMathロガーのようなユーティリティクラスまたは真のシングルトンがある場合に使用する必要があります。

于 2010-12-30T11:08:02.487 に答える
0

Saurabhのコードに加えて、シングルトンクラスを次のように変更します。

public class MySingleTon
  {
    static MySingleTon()
    {
      if (Instance == null)
      {
        Instance = new MySingleTon();
      }
    }

    private MySingleTon(){}

    public static MySingleTon Instance { get; private set; }
    public IMyRepository MyRepository{ get; set ;}

  }
于 2010-12-30T10:54:09.970 に答える
0

しかし、そのようなクラスのイントラクションを作成するのは良くありません、そして私はこれの背後にある理由がわかりません。

しかし、あなたは以下のコードと同様に行うことができます

Public Interfaceというプロジェクトを作成し、MyRepositoryクラスから公開するパブリック関数を使用してインターフェイスIMyRepositoryを定義します。

IMyRepositoryを返し、アセンブリの外部でも設定できるシングルトンクラスにパブリックプロパティを作成します。

ここで、単一のアセンブリを参照するアセンブリからこのプロパティを明示的に設定する必要があります。他のアセンブリからMyRepositoryクラスのオブジェクトを作成できると思います。

注意：上記の解決策は、循環参照を破るトリックにすぎず、最適な解決策ではありません。

于 2010-12-30T10:50:11.960 に答える
0

クラス自体にシングルトンアクセサプロパティを含めることは一般的に使用されるショートカットですが、複数の関連するクラスのインスタンスを処理する必要があるより複雑な状況では、間違った方法であることが判明する場合があります。問題は、単一のクラス内で懸念事項を混合することです。

あなたのMySingletonクラスはMyClass、実行時に存在するインスタンスの数に一般的に依存しない方法で実装されるものでなければなりません。同様に、任意の数のインスタンスMyRepositoryを管理および提供できる必要があります。MyClassのシングルトンインスタンスのみを処理するという事実は、バインドしてMyClass結合する別のファクトリ（またはアクセサまたはそれを呼び出すもの）クラスにカプセル化できます。MyClassMyRepository

したがって、次の方法で設計を再考してみてください（概略）：

public class MyClass { ... }

public class MyRepository
{
    public MyClass GetMyClassInstance(...);
}

public static class MyClassFactory
{
    public static MyClass SingletonInstance 
    { 
        get 
        { 
            if (singletonInstance == null) 
                singletonInstance = myRepository.GetMyClassInstance(...);
            return singletonInstance;
        }
    }
}

残りの質問はどこmyRepositoryから来るのかです。たとえば、プログラムの起動時に作成しMyclassFactory、メンバーフィールドとしてプロビジョニングできます。

結局のところ、制御の反転を使用することを検討すると、多くのことが簡単になります。次のステップも、インターフェイスベースの設計に移行することです。これにより、抽象化の別のレイヤーが提供され、実装の互換性に関してより柔軟になります。

于 2010-12-30T10:51:01.093 に答える