ビジネスレイヤーでのキャッシュとデータレイヤーでのキャッシュ

私は常に、DALでキャッシングが行われるプロジェクトに取り組んできました。基本的には、データベースへの呼び出しを行うときに、キャッシュにデータが既に存在するかどうかをチェックし、存在する場合は呼び出しを行いません。代わりにそのデータを返します。

私は最近ビジネス層でのキャッシュについて読んだので、基本的にビジネスオブジェクト全体をキャッシュします。すぐにわかる利点の1つは、応答時間の短縮です。

どちらを優先するかはいつですか？およびビジネス層でのキャッシングは一般的な慣行ですか？

c# design design-patterns caching

— エマ
ソース

アプリケーションのパフォーマンスは非常に重要なため、リポジトリまたはDALレイヤーへの追加の呼び出しが明確にならないようにするよりも、ビジネスレイヤーでのキャッシングが望ましいですか？

— JDT

いいえ、返信を読んだ後は、DALでのキャッシュのみに固執すると思います。乾杯。

— エマ

ビジネスレイヤーの上のキャッシュを検討し、スケーリングについても検討する必要があります。

— AK_

回答:

これはおそらく決定的な答えには広すぎます。個人的には、データアクセス層はキャッシュに適した場所であると感じています。単純にそれが非常に単純であると想定されているからです-レコードが出入りするだけです。

ビジネス層はより複雑な多くの追加ルールを実装しているため、同じクラス（または同じメソッド）での複数オブジェクトの一貫性の問題に加えて、オブジェクトごとの可用性の問題も管理する必要がない場合は、より適切です。SRPの露骨な違反であること。

（もちろん、キャッシュと構成の両方を同時に実行しようとしたときに、サービスクラスが手に負えないほど複雑になった後、その洞察に達しました。経験よりも優れた教師はいませんが、価格は確かです。）

— キリアン・フォス
ソース

キャッシングを複雑にする必要があるのはなぜですか？AOPといくつかの注釈を使用して実行できます。まだSRP違反ですか？なぜDALで行われないのですか？IMHEまた、キャッシュされる「複雑すぎる」サービスクラスを見たこともありません。サービスはその複雑さに関係なく、ブラックボックスと見

— なされ

データアクセス層と永続化/ストレージ層は、非常に自然なキャッシングの場所です。I / Oを実行しているため、キャッシュを挿入するのに便利で簡単な場所になっています。ほぼすべてのDALまたは永続化レイヤーは、成熟するにつれてキャッシュ機能を与えられることを敢えて言います（最初からそのように設計されていない場合）。

問題は意図です。DALおよび永続層は、レコード、テーブル、行、ブロックなどの比較的低レベルの構造を処理します。彼らは、「ビジネス」またはアプリケーション層のオブジェクトを見たり、それらがより高いレベルでどのように使用されているかについて多くの洞察力を持っていません。少数の行または数十個のブロックが読み書きされているのを見ると、それらが表すことは明らかではありません。「現在分析中のジョーンズアカウント」は、「アプリが一度だけ必要とし、再び参照することのない基本的な税率参照データ」とそれほど変わりません。この層では、データはデータであり、データです。

DAL /パーシスタンスレイヤーでキャッシュすると、そこに「冷たい」税の参照データが置かれ、12.2MBのキャッシュを無意味に占有し、実際にはわずか1分で集中的に使用されるアカウント情報を置き換えます。最高のキャッシュマネージャーでさえ、高レベルのデータ構造と接続に関する知識が乏しく、近々どの操作が行われるかについての洞察がほとんどないため、推測アルゴリズムに戻ります。

対照的に、アプリケーション層またはビジネス層のキャッシュは、それほどきれいではありません。他のビジネスロジックの途中にキャッシュ管理操作またはヒントを挿入する必要があり、ビジネスコードがより複雑になります。しかし、トレードオフは次のとおりです。マクロレベルのデータがどのように構造化され、どのような操作が行われるかについての知識があれば、最適な（ "clairvoyant"または "BéládyMin"）キャッシング効率を概算できます。

キャッシュ管理の責任をビジネス/アプリケーションコードに挿入するのが理にかなっているかどうかは判断の呼び出しであり、アプリケーションによって異なります。多くの場合、DAL /永続層では「完全に正しい」ことはできないことが知られていますが、トレードオフは、かなり良い仕事をすることができるということです。、その低レベルのキャッチにより、ビジネス/アプリコードの複雑さが増すことを回避できます。

複雑さが低いほど、正確性と信頼性が向上し、市場投入までの時間が短縮されます。多くの場合、これは大きなトレードオフと見なされます。完全なキャッシュは少なくなりますが、品質は向上し、タイムリーなビジネスコードになります。

— ジョナサン・ユーニス
ソース

返信いただきありがとうございます。あなたと他の人の返信を読んだ後、私は間違いなくビジネス層にキャッシュする必要はないと思います。製品の全体的な複雑さが増すだけです。

— エマ

「レイヤー」モデルの問題の1つは、効率的なキャッシングメカニズムでは、多くの場合、単一のレイヤーでは利用できない情報を使用する必要があることです。しかし、ビジネスレイヤーがデータレイヤーに全体的な「計画」について「ヒント」を渡すとしたらどうでしょうか。データレイヤーは最初はそのようなヒントのほとんどを無視できますが、ボトルネックが見つかった場合、特定のヒントが与えられるとビジネス固有の方法でキャッシュ戦略を変更するロジックを追加できます。

— supercat

素晴らしい点、@ supercat。ヒント/プラグマ戦略について言及するつもりでしたが、答えはすでに長くありました。しかし、あなたはまったく正しい。キャッシュを優先する方法、つまり「固定する方法」に関する下位層へのビジネス層のヒントは、ビジネスコードをすべて行わせることなく、または独自のストレージの管理に追いつくことなく、高レベルのキャッシュを取得するための非常に一般的/便利な方法です階層。

— ジョナサン・ユニス

@JonathanEunice：ヒントの良いところは、最初はコードで何もする必要がないということです。多くのシステムには、パフォーマンスを左右する明らかなボトルネックがいくつかありますが、どれが問題になるほど悪いかを予測するのは難しいかもしれません。少数の重要な箇所に少量のいキャッシュロジックを追加することは、実際には重要ではない場所に大量のキャッシュロジックを配置するよりも優れている場合があります。

— supercat

まさに。特に、永続性/アクセス層に既に「かなり良い」低レベルのキャッシュがある場合。「かなり良い」から「本当に良い」に進むために、少し追加された優先順位情報のみが必要な場合があります。

— ジョナサンユニス

DALでのキャッシュは簡単でシンプルです

DALは中央のデータアクセス層です。つまり、すべてのデータアクセスは、そこにあるクラスを介して制御できます。これらのレイヤーで読み取りと永続化の両方が行われると、変更が発生したときにキャッシュエントリを簡単にクリアまたは更新できます。

ビジネスでのキャッシュは柔軟です

ビジネスでのキャッシングにより、開発者はオブジェクトの具体的な使用がキャッシングの恩恵を受けるかどうかを柔軟に判断できます。アプリケーションの構造に応じて、バックエンドサービスまたは自動化されたプロセスにより、他の部分にキャッシュされるデータが変更される場合があります。開発者は、ビジネスのキャッシュを使用して、特定のビジネスオブジェクトが失効した可能性のあるデータを使用してパフォーマンスを獲得するか、パフォーマンスを犠牲にしてビジネスオブジェクトの最新の状態にするかを決定できます。

— JDT
ソース