checkout process workflow, having issues with redirects

My checkout process has the following workflow:

1. checkout page
2. shipping address
3. edit shipping addr开发者_运维问答ess(add/edit)
4. delivery method
5. payment
6. place order

Each of the above steps has its own action in the same controller.

Now the issue is, if the person gets to #5, and wants to edit the address, they go back to #3. But when they hit submit, they go to the next step, #4, but they should go straight back to #5.

I know I can pass information via a query string/form and tell #3 to check for the presence of that key, if its there, then redirect to #5.

Are there any proven, best-practice techniques to manage a workflow like this in asp.net-mvc (or in general)?

Usually I will set up a session to store the state and data of the user, and from determine which step to go on to next. Hence the controller upon being invoked could run some logic to determine which state the user is at, and then invoke the rendering code to output the form associated with the user's current state.

IMHO, this streamlines the process as you don't delegate the 'what's my next state' checking to the forms level, but to a centralised location, which makes it easy to add in new business logic down the road.

Hope this helps!

(You could replace session with invisible form fields, query strings and etc.)

If you really do "hate sessions" as you say, there is potentially another option, which is to pass a querystring for all "backward" operations defining where to go next.

This is how most Login pages work -- if you are not authorized to view a page, it will redirect to the Login page with a redirectUrl querystring parameter set. Then on successful login you'll be redirected to the page you originally came from.

And just to simplify your code a little you could overload the RedirectToAction() method on your controller such that it redirects to the given action UNLESS there's a that special querystring, in which case it redirects there.

edit: I know that you mentioned this as a possibility, but I posted it anyway because: 1) there's nothing wrong with it (especially if you "hate sessions"), and 2) you mentioned having your Action check for the presence of the key, which I think could be better written as I described (using an overload -- DRY)