5

アプリケーションにいくつかの「キャッシュ」オブジェクトがあり、IRepository依存性注入（Ninject）によって（カスタムリポジトリパターンコントラクト）を取得します。これらのオブジェクトはリポジトリを1回だけ使用しますが、所有者に自分自身を更新させる更新機能があります。それらはシングルトンであり、一度だけ作成され、ManualResetEventロードされるまですべてのリクエストがブロックされることを保証します。

EF CodeFirstベースIRepositoriesなので、接続が閉じていることを確認し、そこへの参照を永久に保持するだけで大​​丈夫ですか？DbContext

プロキシと遅延読み込みを無効にしたので、キャッシュオブジェクトのルートからこれらのキャッシュされた数百のPOCOエンティティへの長い参照があっても大丈夫ですか？

乾杯。

4

2 に答える 2

2

Julie Lermanからのコメントを参照します。http ：//msdn.microsoft.com/en-us/magazine/ee532098.aspx？sdmr = JulieLerman 推奨事項は、いくつか/多数の小さいコンテキストを使用することです。Webシナリオの場合は、呼び出しごとに新しいコンテキスト。彼女はEntityFrameworkとAppFabricの第2レベルのキャッシングについて書いていますが。

時間の経過とともに、コンテキストには多くのオブジェクトが含まれ、それに応じてパフォーマンスが低下します。このサイトには、EFのパフォーマンスに関するいくつかの良いヒントがあると思います。例：生成されたビュー。 http://msdn.microsoft.com/en-us/data/hh949853

私の個人的な推奨事項は、ベストプラクティスであるとは言えませんが、パフォーマンスを懸念している人からは、呼び出しごとに小さな制限のあるコンテキストが確実な長期的な妥協点であるということです。生成されたビューを使用して、初期ロード時間をできるだけ短くします。

未使用のオブジェクトをコンテキストから削除するような方法で、永続的なDBContextを管理できる可能性があります。または、イベントを含むキャッシングライブラリを使用してこれを行います。小さな仕事ではありません。

私はあなたが最終的に選択する解決策に興味があります。投稿してください。

于 2013-01-21T13:50:47.983 に答える
0

最後に、私が見つけた最善の解決策は、新しい種類のラッパーを作成することです。

    public class Generator<T> where T : IDisposable
    {
        readonly Func<T> _generate;
        public Generator(Func<T> generate)
        {
            _generate= generate;
        }

        public T Generate()
        {
            return _generate();
        }
    }

そして、多かれ少なかれこの方法でバインディングを作成します。

// Dependency Injection bindings declaration section
DI.Bind<Generator<IRepository>>()
  .To(()=> new Generator<IRepository>(()=> DI.Get<IRepository>()));

したがって、要素を作成して破棄するだけでよい長寿命のオブジェクトではGenerator<IRepository>、ではなくサービスを要求できますIRepository。したがって、更新が必要になるたびに、内部でどのように構築されているかを知らなくても、新しいIRepositoryを作成するだけです。

 using (var repository = repositoryGenerator.Generate())
 {
     repository.DoStuff();
 }

これまでのところ、それは魅力のように機能します。

実際、私はこの機能をDIフレームワークに追加しました。これで、IAnythingをバインドでき、後でGeneratorの要求に応じて、フレームワークはこの手法を使用して完全に準備ができたオブジェクトを提供します。プログラムでFunc<>デリゲートを作成する方法

乾杯。

于 2013-10-24T14:37:37.797 に答える