0

私はEntityFrameworkを初めて使用し、コンステレーションEF、LINQ、POCO、およびリポジトリについていくつかのポイントを取得したいと思います。

EFとPOCOを使用してデータベースにアクセスするリポジトリを備えた実用的なソリューションがあります。コンテキストを介してLINQですべてのクエリを実行しています。データベース/テーブルがすでに存在するため、アプリケーションの開始時にロードされるマッピングクラスにマッピングを追加しました。

特定の会社について、従業員が子供のために購入したおもちゃの量を計算する必要があるビジネスケースがある場合。

リポジトリ/リポジトリをどのように構築しますか？

A：1つのリポジトリで会社のすべての従業員を呼び出してから、サービスレイヤーで、子供などのすべての従業員に対して別のリポジトリを再度呼び出しますか？

B：すべての従業員、子供、おもちゃを持った会社を返す1つのリポジトリに電話しますか？

Aは私にははるかにクリーンに思え、リポジトリをより頻繁に再利用できます。しかし、Bの継ぎ目はより効率的ですが、それほど再利用可能ではありません。リポジトリとクエリが少なくなると、ますます大きくなります。

これはほんの小さな例です...しかし、はるかに大きなビジネスケースがあります。この場合の最良のアーキテクチャアプローチは何ですか？

class Company
{
    List<Employee> employees;
}

class Employee
{
    List<Child> children;
}

class Child
{
    List<Toy> toys;
}
4

2 に答える 2

0

会社、従業員、子供、おもちゃを入手するためにリポジトリを呼び出す必要はありません！

特定の会社について、その会社の子供たちのために従業員が購入したおもちゃの量を計算する必要があります

したがって、ビジネスケースは、単一の番号、またはおもちゃごとの番号、または従業員ごとの番号を持つことです。これらすべてのエンティティをロードして、アプリケーションで計算する必要はありません。集計クエリを作成する必要があります（LinqまたはSQLのいずれかで）。この計算全体は、データベースで実行されることになっています。

リポジトリの背後にクエリを非表示にする必要がある場合は、このビジネスケースが属するものを選択し、リポジトリの新しいメソッドとしてクエリを公開します。

于 2012-08-10T18:07:08.317 に答える
0

厳格なルールはありませんが、集約ルート（この例ではCompany）ごとに単一の作業単位を使用することは、物事を整理し、同時実行エラーを防止するために最も一貫して機能するようです。すべての配線、およびオブジェクトの管理。作業単位とは何かについてのすばらしいMSDN投稿があります。その記事からの抜粋：

ある意味で、作業単位はすべてのトランザクション処理コードをダンプする場所と考えることができます。作業単位の責任は次のとおりです。

  • トランザクションを管理します。
  • データベースの挿入、削除、および更新を注文します。
  • 重複する更新を防ぎます。Unit of Workオブジェクトの単一の使用法の中で、コードの異なる部分が同じInvoice
    オブジェクトを変更済みとしてマークする場合がありますが、UnitofWorkクラスは
    データベースに対して単一のUPDATEコマンドのみを発行します。

作業単位パターンを使用することの価値は、コードの残りの部分をこれらの懸念から解放し、それ以外の場合はビジネスロジックに集中できるようにすることです。

これについてはいくつかのブログ投稿がありますが、私が見つけた最高のものは、それを実装する方法についてです。このサイトからここ、そしてここで参照されているものが他にもいくつかあります。

Aは私にははるかにクリーンに思え、リポジトリをより頻繁に再利用できます。しかし、Bの継ぎ目はより効率的ですが、それほど再利用可能ではありません。リポジトリが少なくなり、クエリがどんどん大きくなります。

汎用リポジトリはここであなたの懸念を処理し、データオブジェクトごとにリポジトリを簡単に作成できるようにすると同時に、再利用可能で簡単にテストできるようにします。そうすれば、ビジネスロジックを作業単位のサービスレイヤーで処理できるため、同時実行の問題が発生しなくなります。

于 2012-08-10T18:08:02.743 に答える