DAOをキャッシュするためのパターン：戦略またはデコレーター？
Services/DAOs/Domain Modelsパターンでphpシステムを構築しています。今がDAOのキャッシングシステムを実装する時です。
デコレータパターンを使用しますか、それとも戦略パターンを使用しますか？
それぞれの浮き沈みは何ですか？
追加された要件：edalorzoへのコメントでコメントしたように、キャッシュなしでDAOを使用できる必要があります少しの間。同じ方法の場合、キャッシュを持つことは許容できる場合もありますが、そうでない場合もあります。
プロキシパターンを使用したキャッシュの実装を見てきました。特にAOPのようなフレームワークは、これらのほとんどにプロキシを利用します。
本によると 再利用可能なオブジェクト指向ソフトウェアの設計パターンと要素 デコレータとプロキシパターンは似ているかもしれません/
ページ216：
「デコレータはプロキシと同様の実装を持っているかもしれませんが、デコレータは異なる目的を持っています。デコレータはオブジェクトに1つ以上の責任を追加しますが、プロキシはオブジェクトへのアクセスを制御します。
プロキシは、デコレータのように実装される度合いが異なります。保護プロキシは、デコレータのように実装される場合があります。一方、リモートプロキシには、実際の件名への直接参照は含まれず、「ホスト上のホストIDとローカルアドレス」などの間接参照のみが含まれます。仮想プロキシは、ファイル名などの間接参照から始まりますが、最終的には直接参照を取得して使用します」
キャッシュを使用する目的は、実際の件名に直接アクセスできないようにすることなので、私にとってはプロキシのように聞こえます。
上記のコメントはまた、プロキシとデコレータの重要な違いは、プロキシが実際のサブジェクトへのインスタンス化またはアクセスを担当する可能性があることを明確に示していますが、デコレータの場合、そのような参照は動的に提供されます。
プロキシと実際のサブジェクトの関係は、デコレータの場合よりも静的であるように見えます。
そうは言っても、結局のところあなたの場合はデザインがどのように見えるかというよりも意図の問題です。最後に解決策は、メソッドをインターセプトし、キャッシュポリシーに応じてキャッシュへのアクセスを取得するかどうかを制御できるラッパーオブジェクト（ProxyまたはDecoratorのいずれか）を用意することです。
私は過去に両方の方法で実装しましたが、私の経験では、デコレータを使用すると、2つのクラス間で責任が明確に分離されます。データアクセスクラスは、キャッシュを実装していない場合と同じです。