LINQ to SQL：DataContextの再利用

Question

レコードの挿入や削除などの簡単な操作を実行する静的メソッドが多数あります。これらの方法はすべてusingのこのテンプレートは、次のとおりです。

public static UserDataModel FromEmail(string email) 
{ 
    using (var db = new MyWebAppDataContext()) 
    { 
     db.ObjectTrackingEnabled = false; 
     return (from u in db.UserDataModels 
       where u.Email == email 
       select u).Single(); 
    } 
} 

私もDataContextを使用する複数の操作を実行する必要があるいくつかの方法があります：

public static UserPreferencesDataModel Preferences(string email) 
{ 
    return UserDataModel.Preferences(UserDataModel.FromEmail(email)); 
} 

private static UserPreferencesViewModel Preferences(UserDataModel user) 
{ 
    using(var db = new MyWebAppDataContext()) 
    { 
     var preferences = (from u in db.UserDataModels 
          where u == user 
          select u.Preferences).Single(); 

     return new UserPreferencesViewModel(preferences); 
    } 
} 

私はのどに簡単な操作を分割できることを好みます私のデータモデルのストアドプロシージャはFromEmail()のような静的メソッドを使用していましたが、私はPreferences()が2つの接続を呼び出す（右？）のコストを心配しています（using DataContext）。

私はする必要がありますか？単一のusing(var db = new MyWebAppDataContext())文を使用するより効率が悪いですか？

Answer 1

これらの「2つの」操作を調べると、1回のデータベース往復で実行できることがわかります。 データベースのラウンドトリップを最小限に抑えることは、パフォーマンスの最大目標である（データベースioを最小化することより2番目）です。

複数のデータコンテキストがある場合、同じレコードを別々に表示します。通常、ObjectTrackingでは、単一のレコードを表すために常に同じインスタンスを使用する必要があります。 2つのDataContextがある場合、それぞれ独自のオブジェクト追跡を行います。

これを観察しているDC1とそれを観察しているDC2の間で記録が変わったとします。この場合、レコードは2つの異なるインスタンスを持つだけでなく、異なるインスタンスはの異なる値を持ちます。このような動くターゲットに対してビジネスロジックを表現することは非常に困難です。

古いレコードレコードから身を守るために、UnitOfWorkの後にDataContextを必ず削除してください。

Answer 2

通常、1つの論理作業単位に1つのコンテキストを使用する必要があります。ですから、仕事パターンのユニットを見てください。 http://dotnet.dzone.com/news/using-unit-work-pattern-entity

Answer 3

原因として、毎回新しいDataContextを作成する際にオーバーヘッドが発生します。しかし、Ludwigとしてのその良い習慣は次のように述べています。

その接続プーリングを使用しているので、あまりにも高価な操作ではありません。

Answer 4

Iのようなインターフェースを使用してラッパーコンポーネント開発：

public interface IContextCacher { 
    DataContext GetFromCache(); 
    void SaveToCache(DataContext ctx); 
} 

およびコンテキストをインスタンス化するためにラッパーを使用します。キャッシュ内に存在する場合はそこから取り出され、そうでない場合は新しいインスタンスが作成されてSaveメソッドにプッシュされ、将来のすべての実装はgetterから値を取得します。

アプリケーションのタイプによっては、実際のキャッシュメカニズムがあります。たとえば、ASP.NET Webアプリケーションと言ってください。これはアイテムコレクションにコンテキストを格納することができるので、要求に対してのみ有効です。 Windowsアプリケーションの場合、それはいくつかのシングルトンコレクションからそれを引き出すことができます。それはあなたがシーンの下で望んでいたものであってもかまいません。

Answer 5

また、新しいDataContextを作成するのが正しい方法だと思っていますが、このリンクではデータコンテキストを処理するさまざまな方法について説明しています。 Linq to SQL DataContext Lifetime Management