Proper way to maintain (non-critical) state accross multiple asp.net MVC Pages

This sounds like a contradiction in terms, or flamebait, but I'm hoping its not actually.

Background:

I need to maintain a few preferences across the entirety of a user's log in. These preferences mostly affect how something is viewed, although they may be passed to the controller layer to accomplish this. At no time should any of these user/session preferences affect data directly.

Question:

How do I temporarily store data across pages/controllers in an MVC setting, so that the controllers can use it (not depend on it) when convenient.

I am thinking session but searches on session and asp.net MVC turn up lots of material on tempdata, which is not what I need. Rather a dictionary per user session of non-essential data would be ideal.

开发者_如何学编程

Thanks Adam

---

Option 1. You store it on the client-side. Put these settings in cookies, they will be available at each following request.

Option 2. You store it server-side. Put it in session but bind it to user id, it can also be easily accessed.

Option 3. You store it in database. Consequently, load these settings from the db on each request. Alternatively, cache it.

---

I don't believe there's any good reason not to use session. I'd be tempted to say that the moment something is required across pages then it's no longer 'temporary'.

---

You could use MS's distributed cache velocity, backed by a database table if necessary. Maintaining your settings this way only requires some extra memory, and shouldn't bog down your server with extra requests. The settings will also expire when they haven't been used recently, or when enough new settings are placed in the cache.

There is also a session provider within velocity which may do what you want.

---

Using the Session object on the controller/viewpage is probably what you want to do. Normally, what I would do is persist the user choices to a database (preferences table), then use the Session as a cache for the user's Preferences object. I often make this a property on a base controller that is lazy-loaded from the Session, if it exists, or the database, populating the Session as needed.