Add results caching

[GoogleCodeExporter]

Not a bug report but there doesn't seem to be a way to feature request. Just 
playing with dapper, so far really prefer it over a full orm thanks for the 
great work.

One great thing I found when previously working with LINQ to SQL and 
IQueryables was Pete Montgomery's excellent LINQ results cache 
http://petemontgomery.wordpress.com/2008/08/07/caching-the-results-of-linq-queri
es/ 
This is an extension method that lets you easily cache results in ASP.NET 
rather than going back to the database every time. Just wondering if there is a 
way to do a similar thing with Dapper or if this could be added?

Original issue reported on code.google.com by PeterTho...@gmail.com on 2 May 2012 at 4:03

[GoogleCodeExporter]

I suspect you could write this trivially as a second extension method; all 
you'd need to do would be to collapse the query and serialize the parameters 
into a single string key, check the cache, and on miss: execute and store.  Not 
sure this has to be something that dapper adds *specifically*. And in most real 
cases I would advise *not* doing the above, but building the key manually, i.e. 
"CustomersByRegion/London" to take the example from your linked page.

I'm open to thoughts - I'm just not sure this is directly a dapper concern...

Original comment by marc.gravell on 2 May 2012 at 5:58

[GoogleCodeExporter]

I have thought about adding an additional extension method the only thing I was 
thinking about was that the syntax will be a bit ugly as far as I can think how 
to do it.

I think I would have to double pass the parameters:
connection.Query<IEnumerable>("sql query", params[]).FromCache("sql query 
params", params[]);
Any thoughts on this appreciated, I can understand leaving this out of dapper. 

Can I ask the reason you are advising not doing this in most cases? Are you 
just thinking the range of different query parameters values each being cached 
would potentially create a large memory overhead or something more 
fundamentally wrong with it? Just don't want to continue doing something if it 
has an inherent problem.

Thanks

Original comment by PeterTho...@gmail.com on 2 May 2012 at 8:05

[GoogleCodeExporter]

I didn't advice "not doing it"; caching is hugely important. Merely, "getting 
the data" is only one part of caching, and it introduces lots of other concerns 
such as serializability, etc.

What I was saying is that I don't *directly* see this as a "data query" 
concern, but rather: one step above, or (much better) several steps above, 
storing the *processed and ready to use* results of an *operation* rather than 
a *query*.

Original comment by marc.gravell on 2 May 2012 at 8:42