10
このプロジェクトではEntity Frameworkを使用しており、キャッシュプロバイダなしで2種類のキャッシュ（インメモリ、Redis）があります。 lack of second-level cache support in EFのため、私たちはそれを自分自身に実装しました。だから私たちのインメモリキャッシュは、キーがキャッシュのIDであり、値がキャッシュされたオブジェクトであるキー値ペアの単純なセットです。また、Redisを使用するために同様のキャッシングを実装しました。クエリでは、メモリ内キャッシュリストを調べ、それが見つからない場合はredisを調べ、存在しない場合はデータベースに対してクエリを実行します。NHibernateの第3レベルのキャッシュ
エンティティフレームワークエンティティはコンテキストを参照しているため、キャッシュにはDbContextのエンティティを使用できません。マップする必要があります。ですから、たくさんのDTOを作成する必要があります。
私はキャッシュがcross-cutting concernであることを知っていますので、よりクリーンなソリューションを探しています。この理由から、最初に私はMemcachedを（単純なリストを使う代わりに）メモリに使うことに決めました。第二に、最も重要なことに、私はSecond-CacheサポートのためにEFからNHibernateに移行するかもしれません。私はそれがfirst level cache is occupied by session objectを知っています。だから私は2番目のレベルのキャッシュのMemcachedを使用したい。しかし、Redisの第3レベルのキャッシュはありますか？
DTOについてプロキシ（DbContextの）でエンティティを使用する際に問題がありますか？通常、問題は、廃棄されたコンテキストにアクセスできないレイジーローダーのためにロードされていない関連プロパティにアクセスしようとするときに発生しますが、分離エンティティで同じ問題が発生します（どちらの場合もIncludeを使用する必要があります）。再びDTOについて私は常にクローンを実装しています（ただし、エンティティに依存します）。 – bubi
@bubi私は永続性フレームワークのドメインモデルを妥協したくありません。 DTOの作成は、Momento Patternのようなものです。次に、私はエンティティフレームワークhas'nt良いキャッシュプロバイダが欲しい。 –
上記の方法でモデルを妥協することはありません。私はあなたがしたと思うが、もしあなたがしなかった場合は、EFの第2レベルのキャッシュ実装を見てみることができます。 Hibernateについて私はあなたの目的がうまくいくかどうか試してみることをお勧めします。古いプロジェクトがまだHibernateにある間は、私はEFを使っています。 Hibernateに関する問題は、クエリを非常に早期に実現する必要があることが多いことです。あなたが頻繁に/いつもうまくいくと思うなら、それはうまくいきますが、DBで作業する必要がある場合は、HQLまたはSQLを書くか、クエリの早い段階でToList（）を書く必要があります。 – bubi