キャッシングアプリケーションブロックは非推奨になりました(ここを参照)。System.RunTime.Caching名前空間に置き換えられます。ただし、SqlDependencyはSQL Azureでサポートされていないため、データベース駆動型キャッシュにもキャッシュ名前空間を使用できません。
つまり、選択は、SQL Azureから自分で読み取ることによって独自のローカルキャッシュを実装するか、Windows Azureキャッシュを使用するか、または単にオンデマンドでSQLAzureから読み取るかということになります。
ローカルキャッシュは...ローカルであるため、パフォーマンスははるかに向上します:)。バックグラウンドスレッド(書き込む必要がある)は、特定の頻度でキャッシュを更新します。したがって、ローカルキャッシュへのアクセスは、メモリアクセス速度で行われます。ただし、各ノードには独自のキャッシュがあるため、WindowsAzureノード間で完全に同期されるわけではありません。この問題を回避するには、すべてのノードで同時に実行されるように更新ロジックをコーディングできます。
Azureキャッシュからの読み取りは、ローカルキャッシュにアクセスするよりも遅くなりますが、すべてのWindowsAzureノードが同時に同じデータにアクセスできます。それでも、特定の頻度でWindowsAzureキャッシュを更新するスレッドを構築する必要があります。自動的に更新されません。
警告:キーと値のペアのキャッシュエントリのキーを事前に知っている場合は、AzureCacheが適切に機能することに注意してください。つまり、AzureCacheからキーのリストを取得する方法はありません。たとえば、郵便番号/温度のリストを保存する場合、郵便番号がキーになります(これは既知のセットです)。したがって、この目的でAzureCacheを使用できます。Azure Cacheは、既知のキー(セッションID)も持つASP.NETセッション状態を格納するのに役立つように設計されています。
最後に、SQL Azure(またはAzureテーブルなどの別のストア)にデータを保持することも非常にうまくいく可能性があります。ただし、それは、取得するトラフィックの量と、データソースから読み取る回数によって異なります。場合によっては、キャッシュメカニズムの構築が必要以上に手間がかかることを忘れないでください。