How to use Caching within class library project?

[Marko Hrovatič]

Is it possible? I can see in this syntax that everything works from the RequestContext provided by the base Controller:

 

var cacheKey = "some_unique_key_for_order";
        return base.RequestContext.ToOptimizedResultUsingCache(this.CacheClient, cacheKey, () =>
        {
                //This delegate will be executed if the cache doesn't have an item
                //with the provided key
           
        //Return here your response DTO
        //It will be cached automatically
        });

I cannot get the context in my DAL project which handles all DB access.

 

I am currenty using Glav.CacheAdapter - it works similarly but works without context. The thing is, I'd like to remove dependency on as much packages as possible, in this case, remove Glav.CacheAdapter and use what ServiceStack provides, if possible.

 

?

[Demis Bellot]

Note ToOptimizedResultUsingCache is just a handy extension method around the dependency-free ICacheClient interface, e.g:

https://github.com/ServiceStack/ServiceStack/blob/master/src/ServiceStack/ServiceHost/RequestContextExtensions.cs#L47 

var cacheResult = cacheClient.ResolveFromCache(cacheKey, requestContext);
if (cacheResult != null)
return cacheResult;
cacheResult = cacheClient.Cache(cacheKey, factoryFn(), requestContext, expireCacheIn);
return cacheResult;

And ResolveFromCache is another extension method ICacheClient:

https://github.com/ServiceStack/ServiceStack/blob/master/src/ServiceStack/CacheAccess.Providers/CacheClientExtensions.cs#L22

If you want to create the most optimal response, e.g. gzip + json you will need to know what the ResponseContentType and CompressionType are (if any) which is what the above ICacheClient + IRequestContext extension methods provide.

At a minimum you want to inject the ICacheClient since that's the min dependency-free interface all CacheClients implement, see:

https://github.com/ServiceStack/ServiceStack/wiki/Caching

This lets you cache any DTO/POCO.

Cheers,

--
- Demis

http://twitter.com/demisbellot

http://www.servicestack.net/mythz_blog

[Marko Hrovatič]

Hello Demis, thank you for such a prompt response. It seems I cannot do this

 

public sealed class CachedJsonCategorizationProvider<T> : ICategorizationRepository<T> where T : BaseCategory
{
 public ICacheClient _cacheProvider = new MemoryCacheClient();
 ...

 private SortedDictionary<string, T> LoadFromCache()
 {
  // check in Cache
  //return _cacheProvider.Get(typeof (T).Name, DateTime.Now.AddMinutes(5), () => { return LoadCollection(); });   // this is from the previous Cache adapter I used and I want pretty much the same thing from ServiceStack
  return _cacheProvider.Get<SortedDictionary<string, T>>(key);
 }
}

 

if I don't bring in the ServiceStack package. I only need ServiceStack.Text and ServiceStack.Common packages. Or so I thought. Now it seems that for MemoryCacheClient I have to bring in the ServiceStack package. That also includes Redis client and OrmLite which I don't need/want.

 

Is the caching functionality designed to be used standalone and not only within MVC projects or am I trying to bend it to something it wasn't designed for?

 

regards,

M.

[Demis Bellot]

You can hand pick the dlls you want from the projects downloads page:

https://github.com/ServiceStack/ServiceStack/downloads 

You're right you don't need SS.OrmLite or SS.Redis if you only want to use the MemoryCacheClient

Is the caching functionality designed to be used standalone and not only within MVC projects or am I trying to bend it to something it wasn't designed for?

ICacheClient lives in ServiceStack.Interfaces.dll which is a pure, dependency and implementation-free interfaces dll. 

The caching providers are also pure, clean C# classes and are completely decoupled from any ASP.NET or web framework.

You generally don't want your classes to be binded to a concrete implementation and should just expose an ICacheClient property that gets injected by your IOC in your host project. 

public ICacheClient _cacheProvider = new MemoryCacheClient();

Cheers,

[Marko Hrovatič]

Demis,

 

MS introduced Nuget so we could get away from handpicking and manually installing and updating dlls. I am trying to stay with a practice of bringing in Nugets as much as possible.

 

While I solved my caching problem by staying with the current provider because of some other reasons, I now have a problem where I wanted to use just the ServiceStack API features and MVC features (Caching, your Json results, your custom session). So I checked under both packages (ServiceStack.Mvc and ServiceStack.Host.Mvc) and determined the best way to do it was to bring in the Host package. It had dependence on Mvc package and WebActivator.

 

Little did I know it will bring in also the ServiceStack package and this package in turn would also bring in the Redis, the OrmClient, ...

 

While your work is super awesome and we'd like to use it as much as possible, it is becoming increasingly tough to do that the way packages are built and dependent within each other.

 

Now, is it really necessary that we bring in all of these? It kinda feels a bit too much - for instance, what has the Redis client to do with Mvc features? Or OrmLite for that matter?

 

I can't even uninstall those unwanted packages because of the dependencies.

 

Please respond, thank you

[Arxisos]

Hi,

we will soon setup a CI server which will also automatically deploy the NuGet packages.

At this stage we can also think about re-organizing the packages.

As long as we don't have a CI server, the expense for Demis is too great if he needs to deploy many small packages by hand each time.

In the meantime you should download the binaries manually here and pick, what you need: https://github.com/ServiceStack/ServiceStack/downloads

Cheers,

Steffen

[Demis Bellot]

MS introduced Nuget so we could get away from handpicking and manually installing and updating dlls.

You might be surprised to know MS isn't the package manager thought leader here - NuGet was introduced to catch up with how other package managers like Ruby Gems and Node Package Manager (NPM) enhanced the developers workflow.

If you feel so strongly about this you should also file issues/complaints against the default Microsoft VS.NET templates which include a lot more dlls than you actually need. This is done to reduce friction in the developers workflow, where they don't have to hunt down the deps you need to run some of the richer examples.

Now, is it really necessary that we bring in all of these? It kinda feels a bit too much - for instance, what has the Redis client to do with Mvc features? Or OrmLite for that matter?

Although these dependencies aren't required to use ServiceStack, there are built-in features like the Authentication/Authorization, Caching and the Messaging services that do make use of these dependencies and its easier for example purposes to just assumes the required deps already exist. ServiceStack also makes use of these dependencies to replace/enhance problematic MVC features with its MVC PowerPack.

...it is becoming increasingly tough to do that the way packages are built and dependent within each other.

Increasingly tough? you can continue to do how we managed to get by before NuGet existed, i.e. just drop the handpicked dlls you want in your solutions lib/ folder.

As Steffen explains maintaining multiple fine-grained NuGet packages places burden on myself to maintain - once we move to CI deployment of NuGet packages we'll look into having more fine-grained dependencies. Until then you have a few choices: 

  - Ignore the unneeded/unused dll references in your projects (i.e. what everyone who leaves the default dll refs in VS.NET templates do). 

  - Handpick the dlls you want from the GitHub downloads

  - Create and maintain your own fine-grained NuGet packages

Cheers,

[Marko Hrovatič]

1. Knew about other packagers but we didn't have that b4 in MS.NET world, did we?, so MS was the first, don't you agree? And if we have it now, we might as well use it as much as possible (use it correctly, that is).

 

2. I don't want to use MVC PowerPack but do want to use Serializers and ServiceStack JsonResults. For serializers it is nice, you bring in ServiceStack.Text and off you go..

 

But to do something as simple as return new ServiceStackJsonResult() I had to bring in a lot of packages. Actually I thought I will only have to bring in Host.Mvc but then found out it brought in all the rest unwanted dlls.

 

So I did handpick DLLs from GitHub download page and included them manually in my project (it turned out FluentValidation.Mvc3 was everything I needed).

 

3. I remove unwanted packages from MVC templates too like EntityFramework and if I don't want EF in, you can bet I don't want Redis or OrmLite in also. That said, we actually can easily remove EF from default MVC templates while removing Redis package is impossible after bringing in the Mvc or Host.Mvc packages. so it's not quite the same...

 

I do enjoy ServiceStack and the work you did. Anyway, thank you for the explanation and all I can hope for is you revisit the structure. AFAIK the only two packages that are the problem here are Redis and OrmLite.

 

thanks

[Demis Bellot]

1. Knew about other packagers but we didn't have that b4 in MS.NET world, did we?, so MS was the first, don't you agree? And if we have it now, we might as well use it as much as possible (use it correctly, that is).

You're actually wrong there too, OpenWrap was before NuGet. My point is you seem to hold MS guidance as "the one true way" yet they copied to get to where they are - and they're still not even following their advice you claim they're preaching.

2. I don't want to use MVC PowerPack but do want to use Serializers and ServiceStack JsonResults. For serializers it is nice, you bring in ServiceStack.Text and off you go..

And likewise others DO want to use the other stuff, so its currently optimized to make their life easier. 

What do you do with the un-needed MS dependencies in your default templates? its not just EF, there's a bunch of cruft there most don't use, so do you a) Aren't sure what can be removed - so leave them on? b) research what you don't need or c) just ignore that they're there? Most people choose d) which also happens to be the easiest approach in ServiceStack.

Regardless the above options remains, and we'll revisit it once we move to CI NuGet builds.

Cheers,