Correct way to "embrace" statelessness of asp.net MVC

Question

I'm working on updating a mobile website that was built using ASP.NET MVC2 to mimic some functionality of a non-mobile website that was built using traditional ASP.NET forms. This is my first time working in MVC. I've read several before me asking about how to overcome the loss of ViewState, and I get the idea of MVC and why it is stateless, but I'm not sure exactly how to manage instances that required statefulness in the original site.

For instance, I have a view that requires a web service to be called to load a collection of payment plans. The payment plans are loaded and displayed to the user. When the user selects a payment plan, the form will post and I need to do some calculations based on the properties of the selected payment plan and possibly properties of the other payment plans. But, of course, they no longer exist. Options and problems as I see it:

• Call the web service to retrieve the payment plans again
  • Problem 1: This is less efficient. It puts more load on the server than when the payment plans were simply stored in ViewState. The calculation of payment plans is lengthy and deseralizing them vs completely recalculating them was ideal in regards to speed.
  • Problem 2: The server state may have changed since the payment plans that were presented to the user were generated. Calling the same method to generate them again may give a different result, but the payment plans that were presented to the user should be honored.
• Store the payment plans in a hidden field.
  • Problem 1: This would allow me to recreate the list of payment plans after the form submits, pretty much like ViewState, except ViewState takes measures (I think a hash?) to ensure it is not tampered with. I can't have a web-savvy user going and changing all my prices to $0 in their browser then posting the form. I suppose I could also do a hash, but I get the impression this is not the approach meant to be taken with MVC.
• Store the payment plans in Session state
  • I could...we are already dependent on Session and will already need to implement SQL based session to allow scalability. But having a view and action requiring Session state seems wrong and does not seem to follow the advice I've found on this topic: embrace the stateless nature of the web, HTTP, and MVC.

I don't, at all, love ViewState or traditional ASP.NET and so far really like MVC but am just not yet sure how to handle this type of thing. Thanks in advance.

To try avoid my question being construed as being to broad, the question is: When state is necessary, as it seems to be here, how do you store it with MVC2?

Answer 1

I don't see a problem with using Session state or something more global like Application state or Cache. All you're doing is caching a value from the service. This is "optional state". Your code will still work even if you don't find the values you were saving in Cache.

When they say "stateless", this isn't what they mean. They mean that, for instance, the behavior of your controller methods should not depend on previous calls to the controller method. Everything the controller needs to operate should be passed to it on every request, perhaps in ViewBag.

BTW, the web was "stateless" before ASP.NET MVC. It's just that web forms allow you to write code that behaves as though the controls had state, when they really did not.