Почему кеширование ServiceStack в Service, а не FilterAttribute?

Question

В MVC и большинстве других фреймворков службы, которые я пытался, кеширование выполняется через атрибут/фильтр, либо на контроллере/действии, либо на запрос, и его можно контролировать с помощью кэширования профиля в файле конфигурации. Кажется, это обеспечивает большую гибкость, а также позволяет очищать основной код сервиса.

Но ServiceStack имеет его внутри службы. Есть ли причина, почему это делается именно так?

Можно ли добавить атрибут CacheFilterAttribute, но делегировать его вместо этого?

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

Я искал вокруг, но не смог найти ответ. Конечно, это, вероятно, не будет иметь большого значения, потому что кеширование ServiceStack через метод делегирования довольно чистое. И вы редко меняете стратегию кэширования на лету в реальном мире. Так что это в основном из любопытства. Благодарю.

Answer 1

Поскольку шаблон кэширования включает в себя, сначала проверяет, не кэшируется ли он, если не выполнять службу, заполнять кеш, а затем возвращать результат.

Фильтр запросов не позволяет выполнять сервис, а Фильтр ответов означает, что Служба всегда будет выполнять (например, смягчает полезность кэша), поэтому альтернативе потребуется комбинация фильтра «запрос + ответ», логика будет разделена на две несвязанные части. Имея его внутри Сервиса, вы можете видеть и рассуждать о том, как он работает и что именно происходит, он также позволяет получить полный доступ к вычислению уникального использованияHashKey и точно, что и когда (или даже если) к кешу, что сложнее контролировать с общим решением кэширования черных ящиков.

Хотя мы открыты для «выпекания» встроенных общих решений кэширования (либо через атрибут, либо в ServiceRunner/base class). Add a feature request, если вы хотите увидеть это, указав предпочтительную функциональность/прецедент (например, кеш, основанный на Time/Validity/Cache, на основе пользовательского Aggregate root/etc).