I have thought about caching "blocks" of the page and then assemble the entire page before sending it to the user, but are there any better, more elegant solutions to the problem?
Every time the user goes to a new page it is updated. This happens so frequently that caching doesn't really make sense. Accuracy is also important.
DB writes are very expensive. There is no reason why you cant bootleg a caching system to handle the on-refresh updates with things like sessions. One of the problems I always have with recent articles about caching web content is that people seem obsessed with not having ot change the cache at all! That's not the point - the point of the cache is to have regularly used, on demand data easily accessible. A session node is prime material for that. Yes it needs to be updated quite frequently but there is absolutely no need to save it anywhere permanently whilst it is in use! (of course once you get to super-scale apps like Facebook it does then become a problem to maintain all the cached data across multiple locations :) but if you can hold everything on a couple of servers it's not going ot present an issue).
@the OP: caching standard elements of a page is always a good idea. Caching "dynamic blocks" will also be a good approach (it is one I use) on the basis that if only one needs updating you dont have to refresh the whole cache just on portion :)
Just dont og overboard - i.e. if you start to get 20 or so block (though I cant imagine anyone would :S) the overhead of pulling the cache might start to have an effect.