Among programmers, the label of "religious issue" has a well established meaning: it connotes a "third rail" subject that’s better avoided than confronted. This hazard came to mind when I heard one of our senior product managers assert, "We adhere to MVC religiously," in a conversation about our Visualforce technology to be generally unveiled on Monday at our Dreamforce conference.

MVC, or Model/View/Controller, has been described as an architecture with elements of

  • model: an entity representing data or activity
  • view: visualization of the state of the model
  • controller: a facility for changing the state of the model

What MVC does for a development organization, my colleague observed, is to

  • let people with user interface design skills take care of the user interface (the view)
  • let people with programming skills take care of the code that manipulates the flow of user interaction and the manipulation of data (the controller)

Ephraim Schwartz at InfoWorld captures some of the customer excitement that’s springing up at the idea of being able to craft a tailored user experience — or multiple user experiences, for different users or different devices — that all drive against a common, high-availability on-demand database with integral trust and data integration models. The benefits of separating controller and view, and the productivity gains of using libraries of high-function and well-tested components that exhibit that separation, are suggested in that piece.

As for those third-rail issues of "What’s A Controller, Anyway?": Visualforce provides clear separation between concise declarative representation of look and feel on the one hand, and disciplined procedural description of behavior and interaction on the other. Given that deep-dyed discipline, I believe that using the name of Model/View/Controller contributes far more light than heat to the discussion.

If someone wants to quibble about whether Visualforce is "really MVC," my retort would have to be, "Compared to what?" This is as clean an architecture as I’ve seen: I know of no better option for putting designer skills and programmer skills to work on parallel paths, producing an application that’s broadly deployable soon and affordably maintainable down the road.

Get the latest Salesforce Developer blog posts and podcast episodes via Slack or RSS.

Add to Slack Subscribe to RSS