Bennett Dill
Bennett Dill

Reputation: 2915

Persisting Data Across Requests MVC3 and Razor

I am working on an MVC3 and Razor website. The user has to select their way through a few choices before finally working on the data.

For example: Client List -> Version List (Filtered by client) -> Etc (Filtered by version)

Once a user selects a client, they select a version for the client. So I'm passing the client id on the querystring. For each mode of the controller of version I'm passing around the client id. On views that I want to show the client name, I'm querying the database for the client and stuffing it into the ViewBag. This seems very inefficient. I feel like I could use a cookie to hold the client id & name.

Now that I've got my version controller done, I'm facing the same pattern again with each subsequent controller, but now I need to persist both client and version...

What is a preferred approach for persisting information like this across requests?

Upvotes: 1

Views: 4628

Answers (2)

brodie
brodie

Reputation: 5424

You should use TempData, which allows you to pass data between the current and next HTTP requests. Be sure to keep in mind that it uses the session.

Greg Shackles has a great article all about TempData here

see this similar question MVC3 multi step form - How to persist model object

Upvotes: 0

Darin Dimitrov
Darin Dimitrov

Reputation: 1038710

This seems very inefficient

That's what database are made and optimized for => query data based on fields and if you put indexes on those fields it will be screamingly fast. Of course Session, Cookies, Cache are some common techniques that you could employ to limit the number of queries to the database but you will have to assume the possible staleness of data that you are getting this way (if some other thread/process modified the data in the database you no longer get correct results).

So before doing any premature optimizations here's what I would recommend you: hammer your database until you discover that this is actually a bottleneck for your application. Databases might become bottleneck in some very high traffic applications where you should resort to one of the afforementioned techniques (or in some poorly written applications of course but let's exclude this possibility for the moment).

Upvotes: 1

Related Questions