Re: caching design patterns

It seems to me that to each a truly performant enterprise level
application with thick client functionality (a lot of it) you really
need to use caching to the nines.

There are a few open source toolkits for caching, great seem to work
fine either on the server side or on the client.

In the past I have always cached reference data, the fairly static, not
too harmful if it is stale configuration option, setting and lookup
data. Works fine, works well.

BUT to truly turn the fat client into a awesomely snappy user interface
that stuns the audience... I need to cache the fluid activity data -
the orders, the results, the critical data that should be right and
recent if you display it.

Perhaps it is dangerous to even consider caching it but if you do the
reality is in most cases it doesnt change fast enough that you would
then have a blistering killer app.

So how do you do it? I wouldnt even consider it with a legacy
database, but starting from scratch with 100% control over architecture
and every line of the code interacting with the database - it is
tempting.

What if I have medium sized DTO business objects that can be retreived
with a version number from the database. No data can be written
without updating the version number.

When it comes to pulling data in I simply send out my primary key +
version number and either a new object or the locally cached one is
returned.

Could it work? Would you do it?

So many questions, never enough years left to answer them.