Entity Framework と ORM は初めてですが、アプリケーションの動作方法を多少リファクタリングすることを考えているという特殊な状況がある可能性があります。
現在、私たちはインメモリ分散キャッシュ アーキテクチャを使用しています。基本的にはインメモリ データベースとして、かなり非効率的でエラーが発生しやすい方法で使用しています。これにより、永続データとの同期や、キャッシュ内のオブジェクトでさえ一貫性がありません。
コアに戻って、Entity Framework のような ORM の何らかの形式を統合するか、SQL 内に手動でストアド プロシージャを作成して、複雑なクラスの作成に必要なデータを取り込むことを考えています。
SomeDashboard例として、要求された (SQL に格納された) に基づいて設定される多くのプロパティを持つ のクラスがあるとしますが、やなどDashboardの に関連するオブジェクトの多くのリストがあります。次のように記述できます。複数の結果セットをプルバックしてそれらすべてのリストとオブジェクト値を作成する単一の DB 要求を利用するストアド プロシージャ。DashboardProductsReviews
それを行うストアド プロシージャを作成するか、複数のストアド プロシージャを作成してデータを分割して取得する (つまり、より多くの SQL 呼び出しを行う) か、Entity Framework を便乗してすべてのオブジェクトをまとめて断片化する方がよいでしょうか?
揮発性になるもので、頻繁に再構築する必要があります。オブジェクトを構築するたびに非常に多くの接続と非常に多くのリクエストがあるデータベースのスケーリングについて心配していました。
おそらく、これは何らかの方向性を与えるのに十分な意味があります。せいぜいあいまいであることはわかっています。
Entity Framework に関連する質問の他の部分は、既存のデータベースとクラスにすべてをマップするのはどれくらい難しいですか?
大まかに言うと...インメモリ分散キャッシングの統合があまりよく考えられておらず、「先制的に最適化」するような方法で行われたため、解決するよりも多くの問題を引き起こしているように感じます。そのため、根本に戻って SQL を多用し、必要に応じて選択的にキャッシングを統合し、SQL のパフォーマンスが問題になったときに最適なアイデアのように思えます。