3

私は最近、Web アプリケーションで新しいアプリケーションをゼロから構築しています。
(テクノロジーはAsp.Netであり、私が使用している ORM はEntity Framework. 重要な場合)

リクエストごとに広く使用されているパターンセッションが本当に良いものかどうかはわかりません。
私が見たように、このパターンの利点は、データベース セッションがクラッシュするまでキャッシュが増加しないことです。\ 大きすぎて非効率的です。

しかし、リクエストごとに新しいセッションを作成するのは多すぎませんか? これは、すべてのサーバー呼び出しがキャッシュをリセットすることを意味します。オートコンプリートのような単純な ajax リクエストでさえ、まったく新しいキャッシュを持っています。実際、キーストロークごとにキャッシュがリセットされます。

1 回のリクエストで同じ object-entity-row をクエリする可能性はわずかです。

Session per sessionの方が良いパターンではないでしょうか? それは両方の利点を意味します

  1. キャッシュが永遠に増えることはありません。
  2. キャッシュは実際に使用できます...

それで...リクエストごとのセッションが広く使用されているのに、セッションごとのセッションがそうではないのはなぜですか?

説明:

  1. 私がORMセッションを書いたとき、それは と の両方に適用されNHibernate's sessionますEntityFramework's DbContext。
  2. 各リクエストでセッション\ dbcontextのflush-commit-SaveChangesを意味します。
4

2 に答える 2

1

私にとっては、作業単位を単一の要求に制限することによって一貫性を提供することがすべてです。問題が発生した場合に、セッションごとのセッションがどのように機能するかわかりません。

たとえば、複数のリクエストが処理された後、コミットで楽観的同時実行例外が発生した場合はどうしますか？その時点で、いくつかのマージの競合が発生する可能性があります。

したがって、リクエストごとのセッションは、競合の露出を制限し、リクエストスコープの作業単位を作成します。

于 2012-09-23T17:43:39.807 に答える
1

リクエストごとのセッションのパターンは、ORM で使用する場合により自然で堅牢です。ダーティ エンティティを取得する可能性が低くなり、リソース管理がより予測しやすくなります。

私が正しく理解した場合、セッションごとのセッションよりもセッションの下の DbContext インスタンスは、データを変更せずにアプリケーションでのみ使用できます。そうしないと、他のリクエストがデータの変更を実行している間に、リクエストによって予期しないデータが送信されます。また、エンティティ フレームワークのコンテキストがスレッド セーフであるかどうかもわかりませんが、リクエストの処理はマルチスレッドです。

完全にはわかりませんが、Entity Framework はキャッシュ (== ID マッピング) を期待するほど広く使用していないと思います。エンティティ セットを選択すると、すべてのデータがキャッシュ内にある場合でもデータベースにクエリを実行します。新しいエンティティの構築を回避することしかできませんが、ID マップから既存のエンティティを使用します。

キャッシングには他の解決策があり、それらはより優れています。

于 2012-09-23T17:13:59.720 に答える