Salesforce MVC Pattern

General Premise behind the Model-View-Controller (MVC)

Designed to divide software up into three interconnected parts so as to separate the internal representation of the data/information from the way in which it is presented and interacted to. In short - separate the user-interface from the business logic and the data itself.


Where did MVC come from?

From Wikipedia

MVC was one of the seminal insights in the early development of graphical user interfaces, and one of the first approaches to describe and implement software constructs in terms of their responsibilities.

Trygve Reenskaug introduced MVC into Smalltalk-76 while visiting Xerox Parc in the 1970s. In the 1980s, Jim Althoff and others implemented a version of MVC for the Smalltalk-80 class library. It was only later, in a 1988 article in The Journal of Object Technology, that MVC was expressed as a general concept.


Salesforce MVC

Below is a diagram that outlines the Salesforce model-view-controller pattern along with where each element fits into it. We'll dive into each of them.



The model is your database objects in Salesforce. The include the standard Salesforce objects like Leads, Contacts, Accounts, Opportunities etc but it also includes any custom objects you've created. Think of it like this - the "model" represents your data model in terms of MVC.


The view represents the presentation of the data (i.e. the user interface).

  • Pages - While often just called "pages", what we are talking about is Visualforce pages. They are the building blocks of the user interface. Visualforce uses HTML to lay out the appearance of the application interface. Each page is referenced by a unique URL just like a regular webpage. The pages themselves also contain Visualforce Components which can be invoked by simple tags inside the page. 
  • Components - these are both standard and custom Visualforce Components. Think of them like widgets that you can add to your pages. Once you write the code once, you can reuse it on multiple pages. Components are important because they allow for this reuse. Components can be styled with CSS.


Controllers are the building blocks of the actual application logic. The controllers are written in Apex code and they end up controlling and enforcing all the business logic. Remember that one of the key design elements of MVC is to separate the logic from the UI. The presentation layer (the view) shouldn't be mixed with a bunch of business logic. Pages interact with the controller through components which shuttle the data and specifies what happens when the user actually interacts with the UI. Salesforce has pre-built controllers for many of the standard actions like View, Edit, Save. If you want to add new behavior though you can extend or build new controllers (custom controllers) in Apex.