リクエストパターンごとにEFの例を見つけようとしています。
現在、トランザクションごとに作業単位を作成していますが、Web サイトでこれを行っているため、リクエストごとにこれを拡張する方がはるかに便利です。
私はすでにglobal.asaxを使用して、リクエストがページやポストバックからのものかどうかを判断しているので、オブジェクトをcontext.itemsに追加するだけです。
これまでに見つけた例は、コンテキスト自体のラッパーを示していますが、コミット/保存や破棄など、必要な作業単位内の他のメソッドもあります。
シナリオ全体で、作業単位を導入するのに最適な場所がわかりません。コンテキストを注入して、変更のたびに新しい作業単位を単純に作成しますか?
また、リクエストが自然に終了するという事実を考えると、このシナリオでコンテキストを破棄する必要がありますか?
上記の質問に当てはまる、またはアドバイスを提供する例を見た人はいますか?
おそらく、リクエストごとに1つのコンテキストが必要です。コンテキストはその最後に配置する必要があります。
ロギングなどの特別な目的で、リクエスト中に2番目のコンテキストを使用する必要がある場合があります（メインのリクエストコンテキストが保存に使用されない場合でも、常にログアイテムを保存する必要があります）。
これまでに見つけた例は、コンテキスト自体のラッパーを示していますが、コミット/保存や破棄など、必要な作業単位内の他のメソッドもあります。
他の方法は？Context は commit( SaveChanges) との両方を提供しますDispose。
シナリオ全体で、作業単位を導入するのに最適な場所がわかりません。コンテキストを注入して、変更のたびに新しい作業単位を単純に作成しますか?
作業単位が必要ですか? したがって、ほとんどの場合、行ったすべての変更を単一の「ユニット」として保存するには、リクエストごとに 1 つだけ必要です。SaveChanges変更を個別に保存する必要がある複雑なビジネス ロジックが原因で、複数の変更が必要になる場合があります (複数の呼び出しによって同じコンテキストで単純に保存することはできません)。手動で必要な場合は、開始コンテキストに戻る必要があります。注入に関しては、ファクトリを呼び出してコンテキスト インスタンスを取得する役割を担うコンポーネントが、コンテキストの破棄も担当するコンテキスト インスタンスの代わりに、コンテキスト ファクトリを注入することを意味します。
リクエストごとに 1 つのコンテキストだけが必要な場合は、 で作成して でApplication_BeginRequest破棄できますApplication_EndRequest。
コンテキストを破棄する必要があります (つまり、IDisposable)。DI コンテナーを使用し、それに作業単位を挿入し、要求ごとに有効期間を設定することをお勧めします。
リクエストの有効期間中は何度でも savechanges を呼び出すことができます。作業単位に伴う利便性は失われますが、リクエストの最後に 1 回だけ呼び出すと、RTT や待ち時間などが短縮されます。