MVCアプリケーションの静的クラスの永続性

Question

私は過去数ヶ月にわたってWebformsの知識をMVCの知識に移行しました。元々はMVCの懐疑的な人の後で、私はMVCを愛していて、動作すると言います。

私がまだ不明な点は、静的クラスがMVCでどのように永続化されているかだけです。 Webformsでは、アプリケーションにアクセスするさまざまなクライアント間で静的クラス値が共有されていました。静的クラスを使用してユーザー関連の変数を保存する場合、別のユーザーの値を上書きする可能性があります。

私の最初の質問は、これがMVCのケースであるかどうかです。

私の2番目の質問は、私のMVCアプリケーションでDBContextインスタンスをどこに保持するかということです。現在私はそれを静的なDALクラスのパブリック変数として持っています。単一のコンテキストは、すべてのクライアント間で共有されます。

私がこれについてもっと読めばなるほど、これは誤ったアプローチだと思っていますが、各コントローラー内のコンテキストを再現することは繰り返しているようです。

コンテキストを静的クラスに入れることには欠点がありますか？

Answer 1

コンテキストは短命であると考えられますので、反復的に見えるかもしれませんが、各コントローラ内にコンテキストを作成してください。正確であるためには、リクエストごとに単一のコンテキストを使用します。

Answer 2

アプリケーションを存続させている間、単一インスタンスを維持するDbContextインスタンスは良いアイデアのようには聞こえません。私は通常Requestあたり1つのDbContextインスタンスを使用します。続き

はあなたのアプリケーションにDbContextのための適切な寿命を決定しながら、検討する必要があります2ポイントです：

1. は、複数の要求に同じコンテキストを再使用して、あなたが キャッシュエンティティの恩恵を受けることができますし、多くのヒットをデータベースに保存することができますが、 パフォーマンスの問題に遭遇する可能性があります.には、しばらくの間、すべてのデータベースエンティティがメモリに格納される可能性があるためです。

2. コンテキストをあまり頻繁に再インスタンス化することは、高価な操作であるため、 も推奨されません。

あなたは、ほとんどのシナリオで最高の作品要求ごとDbContextをインスタンス化し、これらの2つのアプローチの間、私のためにどこかにバランスを見つける必要があります。

Answer 3

DbConextはスレッドセーフではありません。EFでは、同じコンテキストで1つの並行操作しか許可されません。したがって、要求間で共有することはお勧めできません。 ほとんどの場合、要求ごとのコンテキストが最適なソリューションです。 （ヒント：リクエストごとにインスタンスを作成するautofacのようなIoCフレームワークがあります）