まず、私が何をしているのかを説明させてください。異なるデータベースに分割された注文を受け取り、この非常に大きな注文を印刷する必要があります。注文から必要なのは、さまざまなデータベースからの約 100 列ほどです。私が行っていた方法は、結合を使用してクエリを実行し、すべての列の値を 1 つの大きな Order クラスの変数に割り当てることでした。これが面倒になり始めました。オーダーを構成する 100 人ほどのメンバーで構成される 1 つのクラスを使用する代わりに、私は疑問に思っています。使用するデータベースごとに 1 つのクラスだけを用意して、それで作業する必要がありますか?
これに追加させてください。基本的に、オブジェクトを元のデータベース テーブルまたは結果セットにマップする方がよいでしょうか。個々のテーブルではなく、オブジェクトが結果セットにマップされているためです。
これに対するオブジェクト指向のソリューションをお勧めします。おそらく、データベースはデータの論理グループを表すテーブルで設計されています。これらの各テーブルは、システム内のクラスにマップできる可能性がありますが、場合によっては、オブジェクトを構成する複数のテーブルである場合や、サブクラス化を使用してテーブルがマップされる複数のクラスが存在する場合があります。複数のテーブルのデータを表示する必要がある場合（たとえば、注文に関連付けられた顧客からのデータを含む注文のリスト）、ビュー、結合、またはストアドプロシージャを使用して、次のようなビュークラスのオブジェクトを作成できます。ビュー/結合/spで選択されたデータ。
基本的に、私が説明しているのは、SQLオリエンテーション（テーブル、ビュー、ストアドプロシージャ）からのデータを処理する低レベルのデータアクセス層があるN層データアーキテクチャです。この上には、汎用データオブジェクトを処理し、データベースからオブジェクトを格納/取得するためにデータアクセスレイヤーとインターフェイスする汎用オブジェクトレイヤーがあります。最後に、この上に、アプリケーションがアプリケーションに意味的にリンクされたクラス（注文、顧客、請求書など）で動作する、厳密に型指定されたビジネスオブジェクトレイヤーがあります。このタイプの一般的なアーキテクチャを実装するには、さまざまなパターンがあります。いくつかを調査して、アプリケーションに最適なものを確認してください。
個人的には、単にテーブルデータとしてではなく、ドメインのコンテキスト内でオブジェクトを処理するようにアプリケーションを構造化することで、コードが改善されると思います。理解しやすさと保守性が向上するはずです。アプリケーション全体に動作を分散させるのではなく、ドメインクラス内で動作をカプセル化することができます。もちろん、これはあなたが良い設計慣行に従っていることを前提としていますが、オブジェクト指向デザインを使用することはこれを奨励します。ビジネスロジックとデータロジックを表示ロジックから分離すると、アプリケーションがはるかにテストしやすくなり、モノリシッククラスが相互に関連するより小さく、より焦点を絞ったクラスに分割されます。
この問題を攻撃するためのエレガントでシンプルなアプローチの1つは、ActiveRecordパターンです。
http://en.wikipedia.org/wiki/Active_record_pattern
もちろん、すべてのシナリオで実行できるとは限りません。他の回答に示されているように、他のパターンと統合することもできます。私は、どのアプローチを選択しても、トレードオフに直面すると信じている人です。ではごきげんよう！
個々のデータベースから個別にデータをロードしないのはなぜですか?
たとえば、Order オブジェクトのコンストラクタは次のようになります。
Method New Order(orderId) {
Get Database 1 Details
Load Details into appropriate Variables
Get Database 2 Details
Load Details into appropriate Variables
Get Database **N** Details
Load Details into appropriate Variables
}
これにより、個々の DB に関係する sql の維持が容易になり、DB ごとに数十の異なるクラスが存在することはなくなります。
別の代替手段は、コード内の DataSet を介してアクセスできる複数の結果セットを返すストアド プロシージャを使用することです。
または、結合をデータベースの 1 つの VIEW に変換することで、結合の処理と保守を容易にすることができます。
ここで本当に考えなければならないことの 1 つは、メンテナンスです。コードを 6 か月間読まなかった後、そのコードを維持するのはどれほど簡単でしょうか。また、他の開発者が事前の知識なしにコードを維持するのはどれほど簡単でしょうか。最も維持しやすいと思われるパラダイムを選択し、そのようにコーディングします
個別のデータストアごとにデータを処理するクラスを作成することを検討します。
次に、Facade のようなパターンを使用して、これらのサブシステムをグループ化することを検討します。詳細については、「デザイン パターン」および「ファサード」で Web を検索してください。その後、ファサードは、個別のデータストア内のデータ間の特定の相互作用を説明できます。
私にとっては、論理的にグループ化されたコードを維持する方がはるかに簡単であり、個別のデータ ストアに対して個別のクラスを用意することは、ここでは理にかなっています。
それは本当にあなたの好みのように聞こえます。それをどのように使用したいですか？個別の C# オブジェクトとして操作する方が簡単ですか、それとも複数の SQL テーブルとして操作する方が簡単ですか?
ここでは粒度に反しますが、このオブジェクトを結果セットにマップしたままにし、結合をデータベースに保持する方が良いと思います。
ビジネス ロジックの場合、「注文」は通常、まとまりのある 1 つの概念です (少なくとも、そのように組み立て始めました)。データが複数のテーブル (またはデータベース) にマップされているという事実は、データのキャプチャ方法の成果物でしょうか? 分割する前に、次の質問を自問します。
これらの質問のいずれにも「はい」と答えない場合は、コードがアトミック オブジェクトとして順序のみを処理し、データベースがその発生元の複雑さを隠蔽できるようにすれば、コードがよりシンプルで読みやすくなると思います (そのためにビューを使用することもできます）。
通常、属性の数が多いからといって、インターフェースを分割する理由にはなりません。ただし、注文オブジェクト自体の複雑さ (またはサイズ) が問題の原因である場合は、次のような一般的なアクセサー メソッドを使用して内部的に単純化することもできます。
private object GetOrderAttribute(string attributeName){
// use a data structure (like a hash table) to store and access internally
}
...
output("Quantity: " + GetOrderAttribute("quantity"));
// etc.
もう 1 つの注意点: パフォーマンスが論理システム設計の最初の関心事になることはめったにありませんが、 DBMS はインデックスやその他のメカニズムを使用して結合を効率的に実行し、ロードを回避できるため、データベース テーブル結合を含むほとんどの場合、データベースが結合を行う場合にパフォーマンスが向上します。必要のないディスクからのページ。個々のクエリもすべてそれを行う可能性がありますが、通常、データベースはビジネス ロジック コードよりも桁違いに効率的に実行できます。(もちろん、結合が物理的なデータベースの境界を越えている場合、その利点は失われる可能性があります。)