I've been recently tasked to design part of an accounting system for one of our clients. Implementation-wise, I'm working with the Microsoft .NET framework (C# being the preferred language) using ASP.NET.
One part of the system involved an editor component that had several pages, with each page being a separate step that was needed to be done. Each page had its own set of web controls and form fields, and each page had separate logic for processing the passed data. So, the ASP.NET Page Controller mechanism seemed quite natural.
However, I wanted to centralize some common controller accounting (i.e. shared state and such), and wanted to enforce restrictions, and not have the user access the editor page stages directly; the current step for the record being edited was kept in the DB anyway, for reasons important to the design and the business rules.
Naturally, I thought of doing it as a Front Controller in ASP.NET; I would then transfer control to the view behind the scenes to render the page and to have that page controller do the necessary logic.
My mistake. I was not cutting with the grain. ASP.NET encourages you to use the Page Controller design, what with code behind classes and all. On the other hand, being a Java programmer, I got used to the idea of using RequestDispatcher.forward() from a controller servlet to forward to a view JSP or what not, and have the name and location of the view JSP hidden from the user. Apparently, when using ASP.NET web server controls (System.Web.UI.WebControls), generated post back events go to the absolute URL of the .aspx file that generated them; since post back depends on the
<form> tag, ASP.NET immediately sets the
action attribute to point to the .aspx of the actual page that hosts the control.