Smalltalk's MVC implementation was created with traditional desktop GUI systems in mind. The separation of responsibilities that it represents makes a lot of sense for web-based software; the model is the representation of the business and persistence layers, the controller is the server-side glue, and the view is the HTML rendered for the client browser.

However, in traditional MVC, the view observes changes in the model in order to reflect its current state by responding to events that the model issues. In a standard HTTP request/response situation, this isn't viable.

Model 2 is a derivative of MVC that was implemented in the Java Struts framework, which introduced a potential solution to this issue. Rather than the view and model directly communicating, the controller becomes a marshaling point for changes. It responds to changes in the view and passes them to the model and vice versa, as shown in the following diagram:

MVC/Model 2 on the Web

This is the way in which Ruby on Rails implements MVC and in turn inspired a multitude of similar MVC frameworks for the Web (such as ASP.NET MVC).

This is in contrast to web technologies (such as Classic ASP, PHP, and Cold Fusion), where it's standard practice to create a page that combines logic, rendering, and database access. This can be described (although rarely is) as Model 1 with the MVC implementation as its logical successor. A Model 1 approach leads to the problems, which we described at the beginning of Chapter 1, Introduction, and so the popularization of MVC, in particular the simplified approach that Ruby on Rails took, begins to provide a strong basis for a well-constructed application.

MVC on the Web might follow this request flow:

Of course, with the advent of Ajax, WebSockets, and fully client-side MVC frameworks, this is a very simplified example. It does serve to show how MVC can easily be adapted for the Web and, in fact, suits the Web very well.