2

クライアントアプリケーションが新しいオブジェクトを要求すると、Factoryクラスにその新しいオブジェクトを作成させます。

public class CarFactory{

    public Car CreateCar()
    {
       //create a new car object and send back  
    }
}

carオブジェクトのプロパティは、データベースに格納されているストアドプロシージャを呼び出すことによって入力されます。データベースには、毎日変更される可能性のあるデフォルト値が格納されています。デフォルトのテーブルは、外部システムによって作成されます。

public class Car {
  public List<string> DefaultTyres {get;set;}
  public List<string> DefaultPetrolSpec {get;set;} 
}

したがって、ファクトリ（サービスレイヤーが呼び出す）がCarオブジェクトを作成すると、ファクトリクラスはリポジトリクラスを呼び出し、リポジトリクラスはDBを呼び出してCarのプロパティを設定します...しかし、これらのレイヤーの関係は少し奇妙に聞こえます...

public Car CreateCar()
{
    //create a new car object and send back
    //Call CarRepository.GetDefaultTyres(), CarRepository.GetDefaultPetrolSpec() etc.  
}

私のファクトリー実装は多くのことをしていると思うからです。リポジトリレイヤーを呼び出すべきではないかもしれません（その後、DBを呼び出して車のオブジェクトのデータを取得します）。

皆さんはどう思いますか？FactoryクラスはDBと通信する必要がありますか？彼らがそうしても大丈夫ですか？そうでない場合、それは誰の責任である必要がありますか？

4

3 に答える 3

0

実際の DB 接続を処理する追加のクラスがあれば、それで問題ないと思います。このようなクラスとは、実際の接続を実行し、接続/クエリの例外などを処理するクラスのことです。Factory クラスは DB 関連のものを認識してはならず、それを別のクラス/オブジェクトに委譲する必要があります。

DB へのこの抽象化レイヤーは、単一のクラスだけでなく、クラスの階層ツリー全体にすることもできます。このようなもの：

ここに画像の説明を入力

これらの各サブクラスは、その特定の RDBMS への接続を処理する方法を知っています。

PS: これは単なる例であり、このようにする必要はないことに注意してください。また、このような階層を持つと、これらのクラスにも Factory が必要になる可能性があるため、少し複雑になる可能性があります。

于 2012-06-05T21:02:14.853 に答える
0

時間をかけて学んだことの 1 つは、あなたの質問には 5 つの答えがあるかもしれないということです。そして、それらはすべて正しいでしょう。本当の問題は、あなたがしていることは理にかなっていますか? ファクトリがサーバー上にあり、データベースへの接続がそこに最も近い場合は、そこが呼び出しの場所です。

今では、他の人たちと同じように自分自身に同じ質問をすることがあります. たとえば、車を作るときに工場が車のタイヤとガソリンを作るべきか、それとも車が自分で作る方法を知っているべきか。

したがって、これを検討することをお勧めします。ファクトリが作成しているオブジェクトの膨大な配列がある場合 (これが通常、ファクトリ パターンがある理由です)、すべての要素に公開する基本クラス/インターフェイスがあることが理にかなっている場合があります。 Create メソッド。（私は非常に迅速で汚い例を投稿しています。型を作成するためにリフレクションを行うと、ファクトリをさらに一般的に保つことができます）

例：

   public interface FactoryObject
   {
          void Create();
          void Destroy();
   }

   public class Car:FactoryObject
   {
        public void Create()
        {
             //TODO: Create my tyres and my petrol
             //TODO: Create my fenders and body
        }
   }

   public class Bicycle:FactoryObject
   {
        public void Create()
        {
             //TODO: Create my tyres but I do not need petrol
             //TODO: Create my fenders but I have no body
        }
   }

   public class Factory
   {
        public FactoryObject GetFactoryObject(Type type)
        {
             FactoryObject returnedObject = null;
             if ( type is Car ) returnedObject = new Car();
             elseif (type is Bicycle) returnedObject = new Bicycle();
             if (returnedObject != null)
                  returnedObject.Create();
             return returnedObject;
        }       
   }

このように、ファクトリは FactoryObject を作成することを知っていますが、そのオブジェクトを構築する方法についての限定的な知識はありません。さらに重要なことは、気にしないことです。

于 2012-06-05T21:22:30.930 に答える
0

答えは、複数の (実装された) リポジトリまたは複数のデータベース/その他のデータ ストアが関与する可能性があるかどうかによって異なります。上記に対する答えが「はい」の場合 (現時点で予想される必要性/可能性であっても)、上記の変更が発生した場合に、その変更から Factory クラスを隔離するためのリポジトリ レイヤーを用意することをお勧めします。

車の作り方を知るのは工場クラスの責任です。どのDBに/いつ/どのように接続するかを知ることは、その責任ではありません。通常は、変更とモジュール設計を容易にするために責任を単純にする方がよい

于 2012-06-05T21:05:49.637 に答える