In an ASP.NET MVC application, I am in the process of creating a wizard for a step-by-step information gathering sequence comprised of many different fields in each screen/view/page.
I intend to save the information asynchronously in the background.
What is the pattern recommendation for:
1.The wizard based sequence itself?
2.The incremental saving of information?
Is there a recommendation/template for a typical wizard like applications like these in ASP.NET MVC?
I'm a Java guy but thought I'd share an approach I took with a recent wizard-type flow that might be useful.
First of all, some pages in the flow were only applicable based on input from other pages and the whole thing relied heavily on backend-data that might change (e.g. the user starts the process, saves it as a draft and returns to it but now the backend data has changed in such a way that a some user input that wasn't needed before is needed now).
To handle all of this, I decoupled the backend code from the flow of the pages - the backend code (aka the service layer) had no idea what page the user was on, no idea what fields were on what pages and no clue what page to send the user to next. All it did was validate the entirety of the data structure the user was populating by going through the wizard (regardless of the user having even gotten to parts of the data structure). Every data element that failed validation had an error attached to it. The front-end code (i.e. the controller layer) simply looked for these errors and determined the first page in the sequence of pages that could address any of the errors and sent the user to that page. If the user had just posted that page (and the service layer had added an error to a data element represented by a field on that page), an error message would be displayed (of course, we only wanted to show the users errors for fields they have already seen, would be kinda rude to show them errors on fields that they are seeing for the first time on a first-time-visited page in the wizard).
The disadvantage to this approach is that the service layer is running validations that aren't even applicable yet (as it doesn't know where the user is in the process) but it had a huge advantage - fields could be moved around between pages, pages re-ordered, you name it, and the service layer doesn't have to be touched. The only thing that has to change is the mapping in the controller layer between errors and what pages are used to address them.
After going through several releases of the project with major changes to this wizard, this design has been incredibly resilient (sorry, I'm kinda proud of it).
I don't have any advice on the other part of your question as I've never done that on a wide scale but as I'm sure you know, you just want to AJAX to send the field value to the server when the field loses focus (or a click is made depending on the control) and update your model. If I were to fit that in with my design, I'd perform only domain-validation (e.g. is it parsable as a date) and write it to the db without going through the service-layer validations and then only when they hit continue do I run my service-layer validations (at which point they might see an error such as "The date you entered must be prior to today"). I had a similar requirement - they could save their work at any time so as long as I could write their data to the db (I can't store "abc" into a date field), it would be fine but when they reloaded their saved data and tried to continue through the wizard, the business logic validations would catch any errors.
