Enable caching on a ServiceClientBase about servicestack HOT 5 CLOSED

No problems, ServiceClientBase with virtual method attached.

Yeah ICacheClient was nice helped us seamlessly migrate to a different caching 
providers pretty easily as well.

If you're doing server-side caching you should check out 
'RequestContext.ToOptimizedResultUsingCache' as seen in:
http://code.google.com/p/servicestack/source/browse/trunk/ServiceStack.Examples/
ServiceStack.Examples.ServiceInterface/GetNorthwindCustomerOrdersCachedService.c
s
Basically writes the most optimal result (e.g. gzipped xml/json or serialized 
xml/json) which whenever a cache exists avoids any serialization.

If your doing caching using the ICacheClient you may want to check out 
CacheManager:
http://code.google.com/p/servicestack/source/browse/trunk/Common/ServiceStack.Co
mmon/ServiceStack.CacheAccess.Providers/CacheManager.cs

As it has a nice API that lets you do stuff like:

return cacheManager.Resolve(cacheKey, () => { 
  return base.Send<T>(request);
});

which will send and cache the result and return the cache result from then on.

- Demis

It's getting a bit boring, but thanks once again for etc...

Nice tip about the ToOptimizedResultUsingCache. That's really an elegant 
solution!

The more time I spend with ServiceStack, the more I'm fond of it's hidden gems, 
and the more I realize how difficult it is to convey that to others. Anyway, 
I'm glad you chose to make this an Open Source project. Thanks again.

Yeah no worries I glad you find it useful as well.

Send me a link if you ever get anything deployed on the Internet somewhere, its 
would be good to see what other people are doing with it.

Cheers,
Demis

There seems to be one issues when trying to combine the 
ServiceClientBase.SendRequest<T> with ICacheManager.Resolve<T>

The second one has a class restriction on the template parameter (and I think I 
know why).

I'm not yet sure how to solve that, but I was thinking along the lines of how 
you handle the QueryStringSerializer with statically initialized callbacks (you 
might want to patent that). Any thoughts about this?

Yeah that's the problem with cascading generic restrictions not mixing very 
well. Ultimately it's valid restriction as both methods should only be taking 
DTO's or POCO's anyway. 

A quick solution for you would be to add another method to your subclass with 
this restriction which will then happily call your base method that doesn't 
have one:

public TResponse CacheSend<TResponse>(object request)
    where TResponse : class 
{
    return base.Send<TResponse>(request);
}

Although its appropriate to include this restriction on IServiceClient (which 
will also fix this), it would likely be invasive and introduce compile-errors 
in other parts of ServiceStack including tests so will need to do an Audit of 
code before I can do this.