2

Am a little confused about session state storage. I have an MVC application, there are view models, which are closer to the view, then there are the domain models which have rich behavior. We are required to store some session state in our application and am having a hard time deciding if I should store my view models or my domain models in my session.

We inherited a legacy application and we are forced to extend a ViewModelBase which has a lot of cruft in it. Hence am hesitant to save the view models in session. On the other hand, domain models have behavior in them and it doesn't feel right to store them.

Any ideas?

kayess
  • 3,384
  • 9
  • 28
  • 45
Karthik Balasubramanian
  • 1,127
  • 4
  • 13
  • 36

1 Answers1

1

I would say neither. First, use of the session should be avoided as much as possible. Second, storing objects in the session can be very problematic. Unless you're using in-proc session storage (which you shouldn't), then every other session backing will require that the objects be serialized. For simple classes, that's not too bad, but if you're dealing with hierarchies and object graphs, then it's going to be a ridiculously huge pain.

You haven't given any information about what you're actually trying to accomplish other than just "we are required to store some session state". Required by who or what and why? Perhaps, if you ask about what you're actually trying to do, someone can give you a better solution that doesn't involve sessions at all, or at least only minimally. For example, instead of storing the entity, could you not simply store the id, and use that to pull the entity from the database?

Chris Pratt
  • 232,153
  • 36
  • 385
  • 444
  • We are looking at using Serializable objects to be stored in session. We currently evaluating session providers. CouchBase is one of those providers, since we already use it for other purposes. We are an ecommerce application, we need to be able to track an user's session across different pages. – Karthik Balasubramanian Dec 20 '16 at 15:49
  • That's different. That's just authentication and authorization, and while yes it does use sessions, it doesn't use `Session`. I too run an ecommerce application and the only thing that goes in `Session` for us ever is a promo code, if applied. Oh and shipping and billing addresses for guest checkout. Forgot about that. Still, very minimal usage of sessions. – Chris Pratt Dec 20 '16 at 15:52
  • We also track some of user related information. For example, if the user has expressed interest on something in a page and navigates to another page, we want to store what he expressed interest in into a session, so that when we are on a different page, we can present options to him. Yes, we use caching to do this, but we are looking at using session to achieve this – Karthik Balasubramanian Dec 20 '16 at 21:10