In our webapplication we have a list of questions that have to be answered by the user. These questions are served to the user one by one and will be saved once the last question has been answered.The problem we faced was saving all the 'help'-data that goes with this: storing the index of the last question, returning whether or not you're at the last question, returning the answered questions for the overview, etc.Initially we stored this data each into its own session. This worked, but it also meant we had about 5 different session variables for each type of question list and a bunch of casts. I've removed these session variables by creating a few extra fields in the viewmodel and storing the viewModel in its entirety inside a session. This made sure we had our temporary data persisted troughout requests (each question solved meant a new request), removed a great deal of sessions and made the code more readable.Another example of usage: our local user object gets overwritten every request because it's being obtained from a repository/databasecontext that's re-created every request (ninject). This also meant that we couldn't just keep a temporary list in our user that holds the already answered questions their answers, since it'd be emptied every request. Using this approach we can save this list in the session object, write it to the local user at the start of the action method, perform the action (save a new answer) and afterwards obtain this list and write it to the viewmodel. It's a bit of a workaround, but it made sure we could keep this data.I believed this to be a decent solution, but now one of the project members (it's a school project due tomorrow) expressed his doubt about this method and said it was a very dirty solution (no alternative provided though).We're using ASP.NET MVC 4.Have I approached this the right way? How should I have solved it differently?
How to persist temporary data over multiple HTTP requests?
mvc;http request
Go with the ASP.NET Session object - it was made exactly for persisting temporary data over HTTP requests and it sounds like it was working for you.Your project mates should recognize that a dirty solution which is working is better than a clean solution which is not. Real-world software development is about iteration and shipping working software.15 session variables is ok. If you're worried about performance - remember never to optimize prematurely. If you're worried about cleaner abstractions - remember you can store strongly-typed objects in Session.My suggestion is to model the answers/progress i.e. as a class and store that in Session.p.s. hope your presentation went well!