Check out To MVC... and Beyond. The author makes some good points. Possibly the most important point is that while web architectures are typically referred to as being MVC, they are very different from the MVC design as applied to GUI programs.
The MVC pattern ... was developed for use in a point-and-click GUI environment. Although the Web is arguably a graphical user interface, it is not a GUI: it is quite different from the event-driven, instant-feedback world of MVC's origin. Although they share the same rough object model -- there are objects in each that can be called Model, View, and Controller -- they should be known by different names. For this article, I will distinguish them as GUI-MVC and Web-MVC.
Where before the controller was responsible for many nuances of user activity, in Web-MVC its role is essentially reduced to a single three-step algorithm: read the servlet parameters, decide which data methods to call, and decide which view to display next.
On the other hand, the Web-MVC pattern deals with several questions left unasked by GUI-MVC. While GUI apps are mostly modeless, Web applications suffer from complex rules determining the transitions from view to view. These nuances of page flow and navigation usually find their way into the Controller role of Web-MVC. In more sophisticated frameworks (e.g. Blueprints, Struts) there are separate actors to handle these navigational tasks: gatekeepers, Screen Flow Managers, page flow configuration files, and so on.
And he points out exactly what I did in my last post:
[The architecture I describe] can apply equally well to an application with many pages, or with nested views. Nested views are a common technique. A given HTML page usually consists of several high-level components (viz. Title, Banner, Navigation Bar, Body, Footer). Each high-level component can consist of many low-level components (viz. Form, Anchor, Paragraph).
Each of these components can be factored into a miniature Model-View dyad. (The controller is usually superfluous at this level.) This is the approach favored by the JFC Swing components.
He also nails another technique I use:
Some architectures use a single servlet as a gatekeeper or dispatcher, responsible for receiving all input; this gatekeeper performs certain common tasks (e.g. authentication) and then sends the request on to either another object ... for processing. This does not qualify as a Big Ball of Mud; rather, all the succeeding discussion about controller servlets and view servlets applies, only pushed down one layer.
So yeah, I liked that article. I want more. 
You may also want to check out his article on Refactoring to Model-View-Controller.
Wednesday, January 8, 2003
Permalink
Feel free to post a comment below. Please see my comment policy.
Formatting Rules (No HTML):