Entity FrameworkのDataContextオブジェクトを作成して、各CRUDメソッドのusingブロックに配置しても問題ありませんか？
次の機能を実装するwpfアプリケーションを構築しています。
- ユーザー入力を取得し、データベースからデータを読み取る
- それにいくつかの計算を行います
- 複数のタイプのビューでユーザーにそれを紹介し、dbに変更を書き込みます
提案されたアーキテクチャ：データベース->エンティティフレームワーク->リポジトリ->ビジネスロジック->データサービス-> ViewModel
このアーキテクチャを使用する理由：アプリケーション（複数のビュー）と複数のデータベースに存在する複数のシナリオ。したがって、私は抽象化のために真ん中にリポジトリを使用する用意があります。
注意点の1つは、リポジトリが実装されている場合、コンテキストが長持ちすることです。これを克服するために、コンテキストを作成し、それらを各クラッドメソッドのusing（）ブロックに配置しても問題ありませんか？
代わりのアプローチを提案してください。
データアクセスまたはトランザクションごとに1つのDbContextオブジェクトを使用します。
DbContextは軽量オブジェクトです。ビジネストランザクションごとに1回使用するように設計されています。DbContextをシングルトンにしてアプリケーション全体で再利用すると、同時実行性やメモリリークの問題など、他の問題が発生する可能性があります。 。
DbContextは基本的に作業単位を実装します。それに応じて処理します。
DbContextオブジェクトを破棄しないでください。
DbContextはIDisposableを実装しますが、手動で破棄したり、usingステートメントでラップしたりしないでください。 DbContextは自身の寿命を管理します。データアクセスリクエストが完了すると、DbContextは自動的にデータベース接続を閉じます。
これが事実である理由を理解するために、DbContextからのエンティティコレクションに対してLinqステートメントを実行するとどうなるかを検討してください。データアクセスメソッドから遅延読み込みIQueryableを返すと、クライアントが（FirstOrDefault()、ToList()またはそれを反復します）。
さらに読む
DbContextオブジェクトで常にDispose（）を呼び出す必要がありますか？
Entity Frameworkでシングルトンデータコンテキストを使用しない理由
戻るIEnumerable<T>対IQueryable<T>
リポジトリがIQueryableを返す必要がありますか？