Monday, August 6, 2012

caching MVC objects


usually when caching I like to try and cache the network requests. The reason for this is that it is easy to add on to a program without effecting anything else. Unfortunately this is not always the best way - especially when we can receive an object through more than one request. This can happen easily when using a framework that can request single objects and collections.

In my current project this is easily handled as a collection only returns a summary of the object, which means the only true way to get the full object is through a single request just for that. The problem comes when you can make a request for a collection that has the full information on an object. This isn't really an issue if we get the single object first and then get the collection - because we don't know what objects are in the collection. For single object caches to be useful when calling a collection we would need to be able to pass some indicator to the server which objects we already have in cache and then for the server to only pass back that those objects are in the collection rather than the entire information about the object. Then we'd need to change our collection reading to first try and get the object out of cache when parsing that collection.

Where this matters will be if a collection is read in first - providing all the information for an object - then we try to get that single object. If you're using a central store for your objects then this would be a good place to save the information. You can change the flow so that any part of the program that gets a model tries the store first (which it should anyway) and only then if it doesn't exist in the store should it try to query the server. We can then set the object's sync when reading from teh server to save it's information to some persistent local storage.

The trick is then where we read the local storage from. There are two options that I would consider. The first would be to update the store so that it reads all the saved information in at readtime. This is the quickest way as it can read in all the storage at once, however it may slow down the initialization of your program as it will have to parse the json in to your objects before becoming available.

The second solution would be to include the reading in to your sync. Instead of calling the server straight away it can look in local storage for the json data and use that. This is my preferred method as it keeps all caching code in the object sync - however if you have many different types of objects then it could lead to duplicate code across the different syncs, however you may be able to write some middleware or a mixin to handle this cache. It also means that you are only reading what you need out of local storage so although it may mean more reads (and it will have to check local storage everytime it tries to read an object externally) you will only bring in the information that is needed so there will be less memory usage and the reads will be spread out rather than all at once at the start of the application.

No comments:

Post a Comment