MVC (Model-View-Controller)
MVC (Model-View-Controller) is the software architecture pattern that separates an application into three layers: the Model (data and business logic), the View (UI presentation), and the Controller (orchestration between Model and View).
Definition
MVC (Model-View-Controller) is the software architecture pattern that separates an application into three layers: the Model (data and business logic), the View (UI presentation), and the Controller (orchestration between Model and View). In the Salesforce context, MVC is the design philosophy behind Visualforce: a Visualforce page is the View, an Apex Controller is the Controller, and the Salesforce sObject layer (plus any custom Apex classes manipulating it) is the Model. The pattern lets developers separate concerns and produce maintainable code.
While MVC dates from Smalltalk in the 1970s, Salesforce''s Visualforce-era documentation made the pattern explicit for Salesforce developers. Modern Salesforce development has moved to component-based architectures (Aura, Lightning Web Components) that retain MVC-like separation but with different vocabulary (template, JavaScript class, Apex controller via @AuraEnabled). Understanding MVC remains foundational for any Salesforce developer reading legacy Visualforce code or designing modern Lightning Web Components.
How MVC maps to Salesforce development patterns
The three MVC layers
Model: data and business logic. View: UI presentation. Controller: orchestration between the two. The separation is the point: a change to the View (different layout) does not require touching the Model; a change to the Model (different business rules) does not require touching the View. Controllers translate between them.
Visualforce as the canonical example
Visualforce makes MVC explicit. The Visualforce page (the .page file with markup) is the View. The Apex Controller class is the Controller, with public properties exposed to the page and public methods invoked from page actions. The Model is the underlying Salesforce sObjects (Account, Contact, custom objects) plus any helper Apex classes that manipulate them.
Standard Controllers and Custom Controllers
Visualforce supports two Controller patterns. Standard Controllers come from Salesforce: each standard or custom object has a Standard Controller exposing default CRUD operations. Custom Controllers are admin-written Apex classes the page references; they expose whatever data and actions the developer codes. Controller Extensions combine both: extend a Standard Controller with custom Apex.
Lightning Web Component MVC equivalent
LWC retains MVC-like separation but with different vocabulary. The HTML template is the View. The JavaScript class is the Controller (it owns the component state and handles user events). The Apex @AuraEnabled methods are the Model (data access and business logic, exposed for the component to call). The separation is the same; the names are different.
Aura Component variant
Aura Components, the older Salesforce-proprietary component framework, also follow MVC. The .cmp file is the View, the JavaScript controller and helper are the Controller, and the Apex @AuraEnabled methods serve as the Model. LWC modernized this with web-standards-based templates and ES6 modules; the underlying MVC pattern persisted.
When the separation matters
MVC separation matters most for testable, maintainable code. Controllers that mix business logic and UI rendering are hard to test (UI testing requires DOM; logic testing should be pure). Pulling business logic into the Model (helper Apex classes) lets developers unit-test the Model in isolation, then write thinner UI tests for the Controller and View.
Modern Salesforce design philosophy
Modern Salesforce design emphasizes a layered approach beyond MVC. Service layer (Apex classes encapsulating business operations), Repository or DAO layer (Apex classes encapsulating data access), Controller layer (Apex classes exposed to LWC), Component layer (LWC handling UI), and Presentation layer (LWC templates). MVC remains foundational but enterprise-grade Salesforce applications layer more rigorously.
Apply MVC in a Salesforce build
MVC is a design pattern, not a feature to configure. The recipe is to keep the layers separate.
- Identify the Model
Which sObjects does the component touch? Which custom Apex classes encapsulate the business logic? The Model is the data plus the business rules operating on it.
- Build the View
Visualforce page or LWC template. The View should focus on presentation; minimal logic, no direct data access.
- Write the Controller
Apex controller for Visualforce, JavaScript class for LWC. The Controller orchestrates: handle user events, call Model methods, update View state.
- Push business logic into the Model
Keep the Controller thin; push business logic into helper Apex classes (the Model layer). The Model is unit-testable independent of the View.
- Write tests per layer
Unit-test the Model in isolation. Integration-test the Controller. UI-test the View. Each layer''s tests are simpler when the layers are properly separated.
- Refactor when layers blur
If the Controller starts containing business logic, refactor into the Model. If the View contains data-access logic, refactor into the Controller. Keep the boundaries sharp.
- Mixing business logic into Controllers makes code hard to test. Push it into helper Apex classes; keep Controllers thin.
- Visualforce Standard Controllers expose default CRUD. Custom logic needs Controller Extensions or full Custom Controllers.
- LWC vocabulary differs from Visualforce. The pattern is the same; the names (template, class, method) differ.
- Enterprise applications often layer beyond MVC. Service and Repository layers help at scale.
Trust & references
Cross-checked against the following references.
- Visualforce MVCSalesforce Developers
- Visualforce ControllersSalesforce Developers
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does MVC stand for?
Q2. What plays each role in Salesforce?
Q3. Why use MVC?
Discussion
Loading discussion…