Entity FrameworkのDataContextオブジェクトを作成して、各CRUDメソッドのusingブロックに配置しても問題ありませんか？

次の機能を実装するwpfアプリケーションを構築しています。

1. ユーザー入力を取得し、データベースからデータを読み取る
2. それにいくつかの計算を行います
3. 複数のタイプのビューでユーザーにそれを紹介し、変更をデータベースに書き込みます

提案されたアーキテクチャ：データベース->エンティティフレームワーク->リポジトリ->ビジネスロジック->データサービス-> ViewModel

このアーキテクチャを使用する理由：アプリケーション（複数のビュー）と複数のデータベースに存在する複数のシナリオ。したがって、私は抽象化のために真ん中にリポジトリを使用する用意があります。

注意点の1つは、リポジトリが実装されている場合、コンテキストは長期間有効であることです。これを克服するために、コンテキストを作成し、それらを各クラッドメソッドのusing（）ブロックに配置しても問題ありませんか？

別のアプローチを提案すること自由に感じなさい。

データアクセスまたはトランザクションごとに1つのDbContextオブジェクトを使用します。

DbContext軽量オブジェクトです。ビジネストランザクションごとに1回使用するように設計されています。DbContextシングルトンを 作成してアプリケーション全体で再利用すると、同時実行性やメモリリークの問題など、他の問題が発生する可能性があります。

DbContext本質的に作業ユニットを実装します。 それに応じてそれを扱います。

DbContextオブジェクトを破棄しないでください。

はをDbContext実装IDisposableしていますが、手動で廃棄したり、usingステートメントでラップしたりしないでください。 DbContext自身の寿命を管理します。データアクセスリクエストが完了すると、DbContextはデータベース接続を自動的に閉じます。

これが当てはまる理由を理解するには、からエンティティコレクションに対してLinqステートメントを実行するとどうなるかを考えてくださいDbContext。IQueryableデータアクセスメソッドから遅延読み込みを返す場合、クライアントが（を呼び出すかFirstOrDefault()、ToList()それを反復することによって）データを強制するまで実際には実行されないパイプラインを立ち上げます。

さらに読書
ドゥ私はいつも私のDbContextオブジェクト上のDispose（）を呼び出す必要がありますか？
なぜあなたは、Entity Frameworkでシングルトンのdatacontextsを使うべきではない
戻るIEnumerable<T>対IQueryable<T>
万一リポジトリ復帰IQueryable？

理想的には、コンテキストは、1つのトランザクションに対して初期化および終了する必要があります。あなたの場合、コンテキストはビジネスロジックでインスタンス化され、データの読み取り/書き込みのためにリポジトリに渡される必要があります。

アプリケーションの各メソッドでDbContextを呼び出すと、メモリリークが発生します。DbContextの単一のインスタンスを使用します。次の例のコメントを参照してください。

public bool IsInStock(int _ProductId)
{
  var result = false;

  try
  {
    using (var dataService = new StoreDbDataService()) // NB: This line on each method will eventually cause memory leak.
    {
      result = dataService.IsInStock(_ProductId);
    }
  }
  catch (Exception ex)
  {
    Log.LogException(ex);
  }

  return result;
}