How should I integrate session state into an ASP.NET MVC application?

Question

I'm looking for thoughts on how should I use Session in an ASP.NET MVC application? Especially when using masterpages and tryin to just get the data to the masterpage without bypassing the controller. This question started off by me asking a lot of little questions, but then I managed to mould it into a solution which as yet I have not implemented but one which is somewhat workable. Would appreciate any feedback.

---

My proposed solution aka 'what i am about to implement unless someone says stop!'

I have my model classes inheriting from ModelBase -- which contains the information needed by the masterpage (there is only one view per page) for certain things it displays in the masthead or footer as well as configuration driven settings based upon who is logged in.

My best solution is as follows - shown here for a 'products page':

Assumption: I have at some point already stuck certain data in session - for instance perhaps a partnerId which came in through a gateway page, or a currentLoggedInUserEmail property or a fully blown object.

I have a ModelBase class from which every model - such as ProductModel inherits

I have a MySiteControllerBase class (inherits from Controller) - which is subclassed by ProductController.

In my action method in ProductController I create the model for the product view with 'new ProductModel()'. This model class itself knows nothing about session or how to populate ModelBase. It essentially doesn't even know about ModelBase - it just inherits from it. My chained constructor does nothing (because I don't want to pass it Session).

I override View(...) in MySiteControllerBase for all the overloads that take a model parameter. I check to see if that parameter is of type ModelBase and if it is I populate the properties such as partnerid and currentLoggedInuserEmail. Fortunately because I'm inside a class that inherits from Controller I have direct access to Session so i can pull them straight out of there.

This method means that the properties on ModelBase are automatically populated just by me doing 'return View(model)'. However there is an obvious issue if the model for ProductModel needs to access anything defined on ModelBase. It's going to get null because it isn't populated yet.

This issue can be solved by passing in Session to new ProductModel(session) which would in turn pass it up the constructor chain to new ModelBase(session). I really dont like that solution though becasue I like to think of a model as a pretty dumb data structure that shouldn't know about any external data constructs at all. Another solution might be to just wing it, and if i ever find that ProductController needs to consume anything defined in ModelBase that I just create a method MySiteControllerBase.UpdateModelBase(productModel, session) to explicitly populate it inside ProductController. I hope thats clear!

Other questions that come to mind are :

• What about unit testing? Is there any abstraction around Session state in MVC or should I build my own? I did a search in the sourcecode for 'session' and nothing came up!
• How does session tracking work with /REST/FUL/URLS in MVC? Are there any issues ith cookies off that I need to know about?
• Should I think of session differently from how I traditionally have?

Answer 1

Although there is nothing, in principle, wrong with using Session in ASP.NET MVC applications (well, at least nothing more wrong than using it in other ASP.NET applications...), I tend to feel it should be a last resort, when other things don't work.

Although your question is, generally, very well-written, you don't go into any great detail on what you propose to store in Session. The two examples I found in your question are:

• Current user e-mail
• partnerid

The user's e-mail address is already available from forms authentication, if you are using that, and can be added to other ASP.NET membership providers which don't already support it. It's not clear what partnerid actually is, but I'm skeptical that the Session is the only possible place to store it.

On the other hand, it's entirely possible that you need to store stuff you haven't told us about which would really only fit in the session.

So before you go too far down this road, make sure that other solutions are not already available for the data you need to store.