3

アプリケーションの残りの部分を永続化テクノロジから抽象化するデータ アクセス レイヤーがあります。現在、実装は SQL サーバーですが、変更される可能性があります。とにかく、このメイン データ アクセス クラスは、テーブルが大きくなるにつれてどんどん大きくなっていることがわかります (現在、約 40 テーブル)。このデータ アクセス レイヤーのインターフェイスは、データを取得したい任意の質問です。

 public interface IOrderRepository
 {
       Customer[] GetCustomerForOrder(int orderID);
       Order[] GetCustomerOrders(int customerID);
       Product[] GetProductList(int orderID);
       Order[] GetallCustomersOrders(int customerID);
       etc . . .
 }

この背後にある実装は、適切なクエリを実行し、型付きコレクションで結果を返す基本的な SQL ストアド プロシージャです。

これはどんどん増えていきます。単一の責任の実際の中断がないため、かなり保守が容易ですが、クラスのコードは 2000 行を超えています。

したがって、問題は、特定のクラスサイズ (および実際の概念的な結合がない) により、これが分解されるかどうか、また分解される場合はどの次元または抽象化のレベルかということです。

4

4 に答える 4

2

絶対にリファクタリングします。2000行は巨大です。

まず、返品タイプ別に分類します。したがって、製品にアクセスするための1つのクラス、注文のための1つのクラス、顧客のための1つのクラスなどを取得します。

クラスごとに、選択された列のセットはおそらく同じである必要があります。これにより、SQL値をオブジェクトに抽出するときに、単一の変数/メソッドにリファクタリングできます。

また、ロギングや例外処理を含むストアドプロシージャへの実際の呼び出しは、別のクラスに入る可能性があり、またそうする必要があります。

ところで、あなたには単一責任の違反があります。あなたの説明によると、あなたのクラスは現在、次の責任を負っています。

  • テーブルをクエリするためのSQLステートメントを作成します（約40回）
  • ストアドプロシージャへの呼び出しの結果をハイドレイトする
  • ストアドプロシージャの呼び出し

そして、私は-ロギング-例外処理を想定しています

于 2009-12-24T03:47:01.020 に答える
1

大きさだけでも考慮したほうがいいと思います。分解できる次元は常にたくさんあります。内訳は単純にコードを管理しやすくするためのものなので、複雑すぎる次元を選択しないでください。特定の関数がどのクラス/インターフェースで見つかるかを簡単に推測できるように、次元を単純にしてください。

于 2009-12-24T03:03:20.407 に答える
1

これはクラックするのが難しい問題です....まず、複数のファイルとクラスに分割し、次にテクノロジー オブジェクトからビジネス オブジェクトを分割します。ビジネス オブジェクトをデータベース インターフェイス (自分で作成) に基づいて作成できます。将来、DB を変更する場合は、テクノロジ オブジェクトを置き換えるだけで済みます。

悲しいことに、データ スキーマの成長から逃れることはできません。ストアド プロシージャ、テーブル、ビジネス オブジェクトが増えることになります。ただし、新しいテーブルを追加するのではなく、レベルを変更することをお勧めします。

アイテムをリソースとして結合するワークフローを形成することをお勧めします。これは、物理的な依存関係を作成するのではなく、データ レイヤー内の 3 種類のアイテムすべてを関連付けるドキュメントを作成することを意味します。たとえば、ビジネス オブジェクトのコメントに注釈を付けて、どのストアド プロシージャとテーブルを指定するかを指定できます。による。SQL Server のテーブルでもストアド プロシージャに対してこれを行うことができます (スキーマにはテーブルの説明フィールドがあります)。これらのヒントは、全体像を把握するのに役立ちます。

于 2009-12-24T03:06:22.140 に答える
0

言語がそれらに対応している場合は、汎用 DAO を検討してください。必要な呼び出しの数を削減するために、例によるクエリを検討することもできます。

于 2009-12-24T03:07:28.737 に答える