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
This would make things a lot quicker for the user, because they wouldn't have to be calling
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.