0

アプリケーションには、CycleエンティティにマップされたCyclesという参照テーブルがあります。基本的に、NHibernate エンティティにマップされたほとんどのエンティティは、そのテーブルへの参照を保持します。通常、これらのエンティティには次のようなフィールドがあります。

  • 開始サイクル
  • 修正サイクル
  • エンドサイクル
  • サイクル

等

リクエストごとにセッションを使用していますが、クエリの大部分がCyclesテーブルに対して発行されていることをログで確認できます。これは、Cycle ID ではなく、Cycleタイプに属する他のプロパティによってクエリを実行する場合です。

Cycleタイプはほとんど不変で、Statusプロパティを持ち、実際にはこれがサービス クラス (CloseCycleService、Open など) によって変更できる唯一のプロパティです。また、Cycle は削除できませんが、挿入できます。

したがって、 Cyclesテーブルへのクエリの数を最小限に抑えたいと考えています。

アプリケーションキャッシュを使用してASP .NET内にキャッシュし、別の抽象化レイヤーを作成できますが、それを行う前に、それがNHibernateによって提供されるオプションであり、欠点は何ですか?

私が目にする唯一の問題はマルチスレッドです。Cycleはほとんど不変 (かつステートレス) ですが、2 つのリクエストが同じエンティティを同時に変更しようとすると、エラーが発生する可能性があります。でも・・・ほぼ無理です。

Cycles テーブルのすべてのコンテンツをキャッシュに保存するために NHibernate で何ができるか教えてください (ああ、そのテーブルのデータ数が少ないことにも触れていませんでした: 1 か月あたり 1 サイクルなので、現在は約 20 行です。月に 1 行増加します)、Cyclesテーブルに発行されるクエリを最小限に抑えますか?

4

1 に答える 1

2

NHibernate のセカンド レベル キャッシュを SysCacheProvider およびクエリ キャッシュと共に使用します。Cycle エンティティのクエリを作成するときに、.SetCacheable(true) を呼び出します。これにより、クエリの結果が (エンティティ自体と同様に) キャッシュに格納されます。

NHibernate の第 2 レベルのキャッシュは非常にうまく実装されており、同じプロセスで行った変更とキャッシュの一貫性を維持します。データベースで直接変更を行っている場合は、SqlDependencies もサポートしていると思われる SysCacheProvider2 (と思います) を確認できます。

于 2012-09-13T17:14:37.607 に答える