David Starr has a post highlighting what Craig Shoemaker said in his 2/7/05 podcast about object oriented pages, and how to handle redirects.

Redirects are an area that makes true object oriented web development difficult. Being able to move from page to page in a strongly-typed world is tough, and requires a bit of upfront thought and design to create something that is easy to use and easy to maintain.

Personally, while I think the solution Craig outlined is better than nothing, I would prefer to keep the knowledge about page locations and how to get to them away from the page itself. That way, other pages don't have to know about each other, nor do they have to know much about the site structure.

How do you achieve that? A UI Process layer. This way, your pages can concentrate on their task, which is (in most cases) to show data to the user, and collect user input. The page only needs to know how to take some data and display it, and then how to get the updated data back. Then, it takes that data, passes it off to a process layer, and the process layer is then responsible for determining what to do with the data passed to it.

Here's a real world example that I've done. On NationalCityHomeLoans.com, we had a UI Process layer that was responsible for everything that happened while the user was in the application. When a page loaded, it was given an object and it displayed the data from that object. When any action was taken, it put the updated data back in the object and determined the user's action (i.e., jump to page 4, go back, save, etc.). Then , the page took the object and the action, and passed it to our process layer. The process layer, based on what page the user was on, ran the necessary updates, and then used the action to determine where to go next. It then handed the object off to the next page, and the process started all over again.

So what do I think the advantages of the above approach is over Craig's? Mainly that the logic to move from page to page and the hard coding of page locations is maintained in one place - the process controller. Changes become easier as the site structure changes over time. And page development is easier. You just call into the process controller and tell it what you want to do. If that action ever changes - for example, after updating something, instead of going back to that item, you now take a user to a list - and this happens in multiple places - all of that logic can be encapsulated, and maintained in one place.