エンティティフレームワークを使用してDALを実装しています。メソッドが呼び出されるたびにパラメータでコンテキストをインスタンス化または受け取るDALクラス（私はそれらをリポジトリと呼びます）があります。私はそのような行動が好きではありません。私はこの問題については文書化されていませんが、私の常識によると、コンテキストのインスタンス化はあまりにも多くのシステムリソースを消費しています。したがって：DALがエンティティフレームワークを使用して実装されている場合のパフォーマンスを向上させる
そのコンテキストのインスタンス化があまりにも多くのシステムリソースを消費言います。私の常識は私はそれが最適化に来るとき常識はほとんど役に立たない
コンテキストのコンストラクタでは、正確には何か問題があると思われますか？まだはありますか？
1）コンテキストのインスタンス化には高価ですか？
データベース接続を確立するために必要な時間と比較しますか？あなたのサイトのDNSルックアップを実行するのにかかる時間と比較して、ブラウザがページのレンダリングに費やす時間と比較して、
膨大な可能性は、ネットワークを介して実際にデータを取得するのに必要な時間に比べて、コンテキストのインスタンス化に特に時間がかかることではないということです。
2）「はい」と答えた場合は、どのようにデザインの観点からこの問題に取り組みますか？
UnitOfWorkabstractionを使用してください。 Each UnitOfWorkはcontain a single entity contextです。これがWebアプリケーションの場合は、リクエストごとに1つのUnitOfWorkが必要です。
ORMを使用する場合、コンテキストのライフタイム管理が重要です。エンティティ・フレームワーク・コンテキスト・インは、遅延ロードおよび変更追跡のためにロードされたエンティティに関する情報を保持し、そのメモリ占有量は非常に急速に増加する可能性があります。コンテキストを破棄しないと、本質的にメモリリークが発生します。
しかし、コンテキストの有効期間を短く保つことは、おそらく変更トラッキングを利用したいので理想的ではありません。
using (var context = new DataContext())
{
context.Products.Add(product);
context.SaveChanges();
}
上記の例では、コンテキストをあまりにも速く廃棄して、変更の追跡を有効にしています。
Webアプリケーションの場合は、リクエストごとにコンテキストを使用する必要があります。
Winフォームアプリケーションでは、あるフォームから別のフォームに移動するときにコンテキストを破棄することができます。