Is XForms really MVC?

This epic posting on MVC helped me better understand the pattern, and all the variants that have flowed outward from the original design. One interesting observation is that the earlier designs used Views primarily as output-only, and Controllers primarily as input-only, and as a consequence the Controller was the one true path for getting data into the Model.

But with browser forms, input and output are tightly intermingled. The View takes care of input and output. Something else has primary responsibility for mediating the data flow to and from the model–and that something has been called a Presenter. This yields the MVP pattern.

The terminology gets confusing quickly, but roughly

XForms Instance == MVP Model

XForms Model == MVP Presenter

XForms User Interface == MVP View

It’s not wrong to associate XForms with MVC–the term has become so blurry that it’s easy to lump variants like MVP into the same bucket. But to the extent that it makes sense to talk about more specific patterns, maybe we should be calling the XForms design pattern MVP instead of MVC. Comments? Criticism? Fire away below. -m

2 Responses to “Is XForms really MVC?”

  1. Martin Probst

    MVC as a term is badly overloaded anyways. I think the original idea behind MVC in Smalltalk was to decouple Models, Views and Controllers such that multiple Views could present a Model, and all would get properly updated etc.

    In the web context, this just doesn’t happen – maybe except for some long poll applications. A request comes in, you have exactly one view, one model, one controller, and changes are applied before the view is rendered.

    While it’s a bit respectless of the elders, I think we’d better just forget the whole Smalltalk analogy and concentrate on what MVC is today, how it works, and in which places it’s helpful.

  2. Piers

    I agree on many points here, particularly I suppose regarding decoupling the design pattern from Smalltalk; although I think working with Smalltalk is a *fantastic* learning exercise in object oriented design, for most this just is not the world in which we operate. Recently, working with Flex, we’ve shifted from one MVC framework to another, and are using the a Presentation model to straighten things out and tighten up our inversion of control; however, the implementation of the design pattern, which originates with Smalltalk, is so far removed from the original, which would have proved less than useless for our needs.

    Reminds me of your post on Model-Endpoint-Template as a candidate pattern a while back.