0

このリンクで：http ：//code.google.com/p/ehcache-spring-annotations/wiki/UsingCacheable 彼らは言う：

When the above POJO is defined as a bean in a Spring IoC container, the bean instance can be made 'cacheable' by adding merely one line of XML configuration.

キャッシングフレームワークを使用せずに、WeatherとListを静的として宣言するだけで、キャッシングが処理されます。

だから私の質問は、もし私がただキャッシュWeather しList<Location>たいのなら、なぜ私はDAO全体をキャッシュするのでしょうか？
また、舞台裏では、注釈は静的変数に変わりますか@Cacheable？WeatherList<Location>

4

1 に答える 1

0

これは問題のコードです：

public interface WeatherDao {

    public Weather getWeather(String zipCode);

    public List<Location> findLocations(String locationSearch);
}

public class DefaultWeatherDao implements WeatherDao {

    @Cacheable(cacheName="weatherCache")
    public Weather getWeather(String zipCode) {
        //Some Code
    }

    @Cacheable(cacheName="locationSearchCache")
    public List<Location> findLocations(String locationSearch) {
        //Some Code
    }
}

static変数についてのあなたのポイントをよく理解していません。本質的に、からへのマップとからzipCodeへWeatherの類似したマップがあります。このマップは、データベース、ファイル、外部APIなどから取得できます。locationSearchList<Location>

可能なすべての引数をキーおよび対応する値としてマップを作成しますか？もちろんできますが、いくつかの欠点があります。

  • ヒープに大きなプレッシャーをかけます。多くの場合、データの量はメモリに収まらない可能性があり、ディスクにも収まらない可能性があります（考えてみてください：すべての可能な検索クエリとヒットのリストを保存することでGoogle検索エンジンをキャッシュします）

  • ほとんどの場合、ほとんどのキーを使用することはありません。なぜそれらをメモリに保存するのですか？

  • 立ち退きはどうですか？これらのメソッドは、時間の経過とともに同じ郵便番号に対して異なる天気を返す傾向があるに違いありません...

私はあなたの議論を完全には理解していないので、呼び出されたときに舞台裏で何が起こるかを簡単に説明しましょうgetWeather()：

  • 透過プロキシはgetWeather()通話を傍受して検索しますweatherCache

  • そのキャッシュでは、zipCode引数をキャッシュキーとして使用します

  • そのようなエントリが存在する場合（タイプWeather）、すぐに返されます

  • 上記が当てはまらない場合、制御は実際のgetWeather()メソッドに委任されます。APIを呼び出したり、データベースクエリを実行したり、時間のかかる計算を実行したりできます。

  • の結果は、将来の参照用にgetWeather()に配置されます。weatherCache

ここには関係ありませんstatic。

ところで、Spring 3.1は、おそらくこのGoogleCodeプロジェクトを時代遅れにするキャッシング抽象化レイヤーを導入しました。見た目は同じで、さまざまなキャッシュ実装とのシームレスな統合が可能です。

于 2013-01-14T19:33:27.650 に答える