Visualforce Variety of MVC

Recently, I’ve been researching the MVC pattern, which is a method of code organization used by GUI applications. I’d like to take some time to discuss how this software architecture pattern is used by Visualforce, in the hopes of educating the reader and inspiring them to write more organized code.

Let’s start with the basics, by looking at the full lifecycle of a Visualforce page. The official docs are weak, so I’ll give a high-level overview. When a request for a Visualforce page arrives in the Salesforce system, the Visualforce page’s code is pulled out of the org’s database, where it is stored. A web browser can not read this code as it lies, since it contains templating code and Apex logic. Salesforce must first use a Visualforce parser to transform it into HTML. This parser understands standard HTML, Visualforce, and also Apex, and can translate a file containing all three into a single HTML file. This allows the developer to use Apex, which has conditionals, variables, loops, and classes, to dynamically fetch data and interpolate it into the static HTML to produce a rich HTML page, customized for each page requester.

With the basics aside, let’s consider how to organize this code. At one extreme, we could create a single file that has the Apex code inline with the HTML and Visualforce. However, most pages require many lines of Apex code, so this could quickly become large and difficult to maintain. In the interest of maintainability, we must look into it sensibly separating our code into multiple components. The issue of separation of concerns for GUI applications has been around for a long time, and a pattern called MVC has been generally agreed upon. Let’s take a look at how we can use this well-known pattern with Visualforce.

MVC dictates that you separate your GUI application into three functional areas: Model, View, and Controller. The View is the code that directly creates what you see in the GUI, which is HTML and Visualforce in our case. The Model is an object that encapsulates the data that will be displayed in the GUI, which might be leads, accounts, a custom object that is composed of related leads and accounts, or some other data in your domain. The Controller contains the rest of the logic, such as button-press actions, and may only modify the data in the Model.

Rather than the model firing events to signal the view to update, the view automatically updates from the model when it is created. (Image source)

The picture above explains this relationship pretty well. I had to fix one thing, however, to make it better resemble Visualforce’s interpretation of the MVC pattern. As explained above, Visualforce is a view-first architecture, in which a request loads a page, which then spawns the controller, which, in turn, spawns the models for the page to use. This pattern is the same one that is used by Microsoft’s ASP.NET and Java’s JSP frameworks, which some software architects call the Page Controller variation of MVC. A more popular name for this variation is called the Model2 pattern.

That’s it for now; I hope this was small enough to be bite-sized. In this post, I’ve supplied some background information on the MVC pattern and explained Visualforce’s interpretation. This blog post is a foundation on which I’ll base my next post, where I’ll use an example project and actual code to explain how I like to structure my Visualforce pages.