ServiceStack이 FilterAttribute가 아닌 Service에서 캐싱되는 이유는 무엇입니까?

Question

내가 시도한 MVC 및 대부분의 다른 서비스 프레임 워크에서 캐싱은 컨트롤러/동작 또는 요청에서 속성/필터를 통해 이루어지며 구성 파일의 캐싱 프로필을 통해 제어 할 수 있습니다. 그것은 더 많은 융통성을 제공하고 핵심 서비스 코드를 더 깨끗하게 유지합니다.

그러나 ServiceStack에서는 서비스 내부에 있습니다. 이런 식으로 된 이유가 있습니까?

CacheFilterAttribute를 추가 할 수 있지만 대신 서비스에 위임 할 수 있습니까?

ToOptimizedResultUsingCache(base.Cache,cacheKey,()=> { 
    // Delegate to Request/Service being decorated? 
}); 

검색해 보았지만 답변을 찾지 못했습니다. 물론 위임 메서드를 통한 ServiceStack 캐싱은 매우 깨끗하기 때문에 별 차이가 없을 것입니다. 그리고 현실 세계에서 캐싱 전략을 변경하는 경우는 거의 없습니다. 그래서 이것은 대부분 호기심에서 벗어났습니다. 감사.

Answer 1

캐싱 패턴에는 캐싱 여부를 먼저 확인하고, 서비스를 실행하지 않을 경우 캐쉬를 채우고 결과를 반환합니다.

요청 필터는 서비스 실행을 허용하지 않으며 응답 필터는 서비스가 항상 실행되도록 (즉, 캐시의 유용성 완화), 요청 + 응답 필터 조합을 요구할 수 있습니다 논리는 두 개의 분리 된 부분으로 분리됩니다. 서비스 내에서 사용하면 작동 방식과 정확히 무슨 일이 일어나는지 추론 할 수 있으며, 사용 된 고유 한 HashKey를 계산할 수있는 완전한 액세스를 허용하고, 캐시에 언제, 어떤 경우 (또는 심지어 경우에 따라) 제어하기가 더 어렵습니다 일반적인 블랙 박스 캐싱 솔루션으로

우리는 내장 된 일반적인 캐싱 솔루션 (속성 또는 ServiceRunner/base 클래스를 통해)을 '열어'볼 수 있지만. Add a feature request 원하는 기능/유스 케이스 (예 : 사용자 정의 집계 루트/시간에 대한 시간/유효성/캐시를 기반으로 한 캐시)를 지정하여이를 확인하고 싶습니다.