I figured this was more of an architectural question, so I chose to post it here rather than Stack Overflow.

So I'm building an MVC web application and have just finished writing the code that wraps my calls into the DB (DAL) and gives me access via an interface to Create, Update, and Delete my Business Objects. Quick example just so you can get familiar before I go into my real question - here's how I would load up a stored record in the database for someone on the front end:

BusinessObjects.Record record = DAL.LoadRecord(int recordId);

Now once the record is loaded up, I can provide it to the front end (web) via a Model to one of my pages, or by attaching it to the ViewBag or something similar. How it gets there isn't important or what I'm worried about, it's more so how I can maintain state in a stateless (web) environment.

The problem I am dealing with right now is, say I provide this record to the front end, and my page reads from it and generates a UI around it. At this point, the record is more or less gone. It has been created, passed, and read, but because of the stateless environment, is now lost. I can re-create this record based on the data I have on the front end on its way back, but is something like this usually handled by adding this record to the cache, and then just working with it there until it's fully ready to be persisted once again (something like Saver.SaveRecord(record);)?

This would make things a lot quicker for the user, because they wouldn't have to be calling Save and Load every single time a page switched or something happened, but I didn't know if this was the correct architecture or if there's a common pattern that I have ignorantly ignored. I've tried to load up some links and have just found examples of how to set something like this up, but what I really want to know is, should I be setting something like this up, or is there a better way to do it.

You'll have to excuse the beginner question. It's pretty obvious this problem has been solved many times, I'm just unaware of some of the more common patterns for doing so, and therefore wasn't sure exactly what to search for.

1 Answer 1


The answer is "it depends". if you think about what is involved in both caching and getting the data from the database fresh, you instinctively assume it will be slower to get it from the db each time.

We tend to think this because the database is a persistent store, where stuff is written to the database. Therefore it must be slower than an in memory cache right?

Well not always. The db is designed to maximise throughput and also to reliably persist data. It has its own tricks regarding caching that may make it quicker to replay the same query over and over than to put the result in a cache and query that.

A separate cache may be quicker when the database is doing a lot of writes, or is located a way away from the web server, or any number of other options.

My suggestion would be to start with the simple solution that works (direct to db) and design your code in such a way that you can easily switch that layer for a caching layer should it become necessary later.

  • That's true. I could have an interface called like ICache or something that actually uses my DAL for now to do all the loading and saving, but then easily create a Caching layer later and just switch the loads and saves to that. I'd be interested to see what some other people have to say, but I do like this answer.
    – user44797
    Mar 11, 2012 at 15:59
  • No one else likes the question :( So you get the answer!
    – user44797
    Mar 18, 2012 at 6:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.