1. You said, “First, there’s the issue of what to model in the Model. Do I model the back-end data/services/objects or the UI data model? Note that these are different. The UI model is inherently about what’s being displayed. The back-end model is about the inherent behavior of the back-end system.” A System of Patterns says that the Model contains the “functional core of the application” (p 127), encapsulating the appropriate data and providing methods that do app specific processing. The way I read this, the Model does not model the UI at all. The UI is actually the Controller component of the MVC pattern. “The user interacts with the system solely through Controllers” (p 127). If you have 10 different UIs relying on the same back-end (Model component), then you’ll be writing 10 different Controllers.

2. You said, “What is the View, exactly? In the Web world I tend to think of the View as the HTML.” Precisely. The HTML is a View of the data stored in the Model component. It’s true that there may be buttons, text fields, forms, etc. displayed in the HTML, but as soon as a user clicks on something the Controller component is in charge. Perhaps that’s where some confusion creeps in… The View component must collaborate with both the Model and Controller components and therefore will display information from both. Further, “there is a one-to-one relationship between views and controllers.” (p 128) You have exactly one Model component (your back-end) and an equal number of View and Controller components (displays and UIs).

3. You said, “How about the Controller? This one becomes a little more cloudy for me in practice, because I’ve separated out the View completely, so really I’m controlling my back-end state. Which is different from controlling my View state. It becomes more an issue of validating that the state as I know it on the back-end is the same as the state on the front-end. Or, more acurately, to validate that the state transitions the front-end requests are acceptable to the back-end.” Again, you are on the right track. The Controller component, which is really the functional element of the UI (the visual element being handled by the View component) is a messenger. User clicks a button, so the Controller takes that information back to the Model to either update the Model with new data and/or grab some data from the Model to be displayed. There’s your state change. The Controller component works in both directions. Changes to the Model component are communicated to View components via corresponding Controller components. Changes in a View Component are immediately handled by the corresponding Controller component (which is the UI, after all) and communicated to the Model component.

There is one major piece to this pattern that you don’t mention but which seems integral. “The separation of the model from view and controller components allows multiple views of the same model. If the user changes the model via the controller of one view, all other views dependent on this data should reflect the changes.” (p 127) You have, I think, pretty much implied this in your post, but here’s the additional bit… “The model therefore notifies all views whenever its data changes. The views in turn retrieve new data from the model and update the displayed information.” (p 127). So, there’s has to be a notification mechanism in place to keep everything synched up. State change must be communicated through the whole application. The book suggests that a registry be kept of all dependent components. Whenever a View is created a Controller will also be created (one duty of a View component is to create and initialize a corresponding Controller), it needs to register itself with the application, so that it can be notified when something changes.

One more thing. It is possible to completely separate your HTML and your JavaScript. The following chunk is from JavaScript – The Definitive Guide, 5th edition

— begin chunk —
Unobtrusive JavaScript

A new client-side programming paradigm known as unobtrusive JavaScript has been gaining currency within the web development community. As its name implies, this paradigm holds that JavaScript should not draw attention to itself; it should not obtrude.[*] It should not obtrude on users viewing a web page, on content authors creating HTML markup, or on web designers creating HTML templates or CSS stylesheets.

[*] “Obtrude” is an obscure synonym for “intrude.” The American Heritage dictionary cites: “To impose… on others with undue insistence or without invitation.”

There is no specific formula for writing unobtrusive JavaScript code. However, a number of helpful practices, discussed elsewhere in this book, will put you on the right track.

The first goal of unobtrusive JavaScript is to keep JavaScript code separate from HTML markup. This keeps content separate from behavior in the same way that putting CSS in external stylesheets keeps content separate from presentation. To achieve this goal, you put all your JavaScript code in external files and include those files into your HTML pages with tags (see Section 13.2.2. for details). If you are strict about the separation of content and behavior, you won’t even include JavaScript code in the event-handler attributes of your HTML files. Instead, you will write JavaScript code (in an external file) that registers event handlers on the HTML elements that need them (Chapter 17 describes how to do this).

As a corollary to this goal, you should strive to make your external files of JavaScript code as modular as possible using techniques described in Chapter 10. This allows you to include multiple independent modules of code into the same web page without worrying about the variables and functions of one module overwriting the variables and functions of another.

The second goal of unobtrusive JavaScript is that it must degrade gracefully. Your scripts should be conceived and designed as enhancements to HTML content, but that content should still be available without your JavaScript code (as will happen, for example, when a user disables JavaScript in her browser). An important technique for graceful degradation is called feature testing: before taking any actions, your JavaScript modules should first ensure that the client-side features they require are available in the browser in which the code is running. Feature testing is a compatibility technique described in more detail in Section 13.6.3.

A third goal of unobtrusive JavaScript is that it must not degrade the accessibility of an HTML page (and ideally it should enhance accessibility). If the inclusion of JavaScript code reduces the accessibility of web pages, that JavaScript code has obtruded on the disabled users who rely on accessible web pages. JavaScript accessibility is described in more detail in Section 13.7.

Other formulations of unobtrusive JavaScript may include other goals in addition to the three described here. One primary source from which to learn more about unobtrusive scripting is “The JavaScript Manifesto,” published by the DOM Scripting Task Force at http://domscripting.webstandards.org/?page_id=2.

— end chunk —

Food for thought?

Thanks for the post. I am currently working on a design for a very simple AJAX app and came across this when googling for “ajax model view conroller”. Attempting to answer your questions helps me get a better grasp on the MVC pattern.

Cheers,
Ryan