2.2 MVC Mapping on the Lightning Platform
Key Takeaways
- Model maps to Salesforce schema: standard/custom objects, fields, relationships, and much of the data layer accessed by SOQL/DML
- View maps to presentation: Lightning pages, LWC, Aura, Visualforce, page layouts, and related UI composition
- Controller maps to behavior: Apex classes/triggers, plus declarative automation that enforces or orchestrates logic
- Lightning uses a component-based architecture where UI pieces compose apps while still fitting the MVC mental model
- Exam scenarios often ask which feature belongs to Model, View, or Controller—map by role, not by marketing name alone
2.2 MVC Mapping on the Lightning Platform
Quick Answer: On Salesforce, Model is primarily your schema and data (objects, fields, relationships), View is what the user sees (Lightning pages, LWC, Visualforce, layouts), and Controller is the logic layer (Apex classes/triggers and declarative automation that drives behavior).
Why MVC Still Appears on a Salesforce Exam
Classical web apps separate Model, View, and Controller so data, presentation, and behavior can evolve independently. Salesforce does not force you to build a greenfield MVC framework from scratch—the platform already provides those layers—but Platform Developer I still expects you to map product features to MVC roles. That mapping helps you choose the right tool and answer “which layer should change?” scenarios cleanly.
Think in responsibilities:
| MVC layer | Responsibility | Lightning Platform examples |
|---|---|---|
| Model | Structure and persistence of data; relationships; often validation that belongs to the data definition | Standard/custom objects, fields, master-detail/lookup/junction relationships, some formula/rollup definitions, schema accessed via SOQL/DML |
| View | Presentation and user interaction surface | Lightning App Builder pages, Lightning Web Components, Aura components, Visualforce pages/components, page layouts, compact layouts, Lightning record pages, tabs |
| Controller | Application behavior: respond to user/system events, coordinate reads/writes, enforce process | Apex classes (including controllers/extensions), Apex triggers, invocable Apex, plus declarative automation (Flow, approval processes, etc.) that orchestrates logic |
This table is the study anchor. When a question lists features, classify each by role rather than memorizing a single “official” diagram that never changes across releases.
Model: Objects, Fields, and Relationships
The Model is the data shape of your app:
- Standard objects (Account, Contact, Opportunity, Case, Lead, and others) provide a shared CRM model.
- Custom objects and fields extend the model for org-specific processes.
- Relationships (lookup, master-detail, many-to-many via junction objects, external relationships where applicable) define how records connect and cascade.
- Schema metadata drives UI defaults, API shape, and Apex typed references (
Account,MyObject__c).
Developers interact with the model through:
- Schema Builder / Object Manager (declarative)
- SOQL/SOSL for reads and search
- DML for create/update/delete/undelete
- Describe APIs when code must inspect schema dynamically
What is not purely Model?
A Lightning record page that shows Account fields is View consuming the model. An Apex trigger that recalculates rollups in custom logic is Controller behavior operating on the model. Formula fields and roll-up summaries live close to the data definition and often appear in “model/data” discussions, but exam items may still contrast them with Apex logic—read carefully whether the question asks about where data is structured versus where process runs.
Scenario: new business entity
Requirement: track Warranty Claims related to Assets, with claim lines.
- Creating
Warranty_Claim__candWarranty_Claim_Line__cwith relationships → Model - Building a Lightning record page and related list → View
- Writing a trigger or flow to prevent closing a claim with open lines → Controller (logic)
View: Lightning Pages, LWC, Visualforce, and Layouts
The View is everything users see and click:
- Lightning Experience pages composed in App Builder (record, app, home pages)
- Lightning Web Components (LWC) — modern, standards-based UI components
- Aura components — older Lightning component model still relevant in some orgs
- Visualforce — server-oriented pages/components still used for certain UIs and PDF patterns
- Page layouts / dynamic forms / compact layouts — field placement and density without custom code
- Tabs, apps, utility bars — navigation chrome around views
Views should stay relatively “thin”: display data, capture input, fire events. Heavy business rules belong in controller/automation layers so the same rules apply whether the user edits via UI, API, or integration.
Component-based architecture
Lightning emphasizes components, not only whole-page controllers:
- Small components own a slice of UI (header, related list panel, custom chart).
- Parents compose children; events or public APIs communicate intent.
- App Builder lets admins place components on pages—composition is configuration plus code.
Even with components, MVC still helps:
- Component markup/template ≈ View
- Component JavaScript that wires services and handles UI events ≈ client-side controller concerns
- Apex @AuraEnabled / wire adapters / LDS that load and save records ≈ server controller + model access
Exam language may say “Lightning Component framework” benefits: device-aware, event-driven, client-side, component reuse. Map those benefits to View composition with controller services behind them—not to schema design.
Visualforce MVC (classic clarity)
Visualforce maps cleanly and often appears in teaching materials:
- Page markup → View
- Standard controller / custom controller / controller extension → Controller
- sObjects and fields bound on the page → Model
Knowing this classic mapping helps you transfer the same logic to Lightning even when files are split across HTML, JS, and Apex.
Controller: Apex and Declarative Automation
The Controller layer decides what happens:
Programmatic controllers
- Apex classes — services, invocable methods, REST/SOAP classes, Visualforce controllers/extensions, LWC-supporting Apex
- Apex triggers — react to database events (before/after insert/update/delete/undelete)
- Asynchronous Apex — future, queueable, batch, schedulable for work that should not run entirely in a tight UI transaction
Triggers are still controller-layer logic even though users never “call” them directly; the platform invokes them on DML against the model.
Declarative controllers (yes, they count)
Salesforce blurs pure academic MVC because Flow, approval processes, and related automation execute business process without Apex. For exam mapping:
- If the feature orchestrates process, branches, updates records, calls out, or notifies, treat it as controller/behavior.
- If the feature defines structure of data, treat it as model.
- If the feature presents UI, treat it as view.
A record-triggered flow that updates child records on Account change is controller-like automation on the model—not a View.
Separation benefits on the platform
Good layering yields:
- Reuse of the same Apex service from LWC, Visualforce, and integrations
- Consistent validation whether data arrives from UI or API (prefer model + automation/Apex over view-only checks)
- Easier testing of logic in Apex unit tests without browser automation
- Safer UI iteration without rewriting business rules
Exam Scenarios: Map the Feature
Practice classifying quickly:
| Feature | MVC layer | Why |
|---|---|---|
Custom object Invoice__c | Model | Schema entity |
| Master-detail from Line to Invoice | Model | Relationship in data model |
| Lightning Web Component showing invoice total | View | Presentation |
| Page layout with two columns of fields | View | UI arrangement |
| Apex trigger validating invoice status transitions | Controller | Behavior on save |
| Screen Flow guiding a refund | Controller + View | Flow logic (controller) with screens (view) |
Visualforce page with standardController="Account" | View + platform controller | Markup is view; standard controller supplies controller behavior |
| SOQL query in Apex | Controller accessing Model | Logic layer reading data |
| List View button that opens an LWC | View entry point | UI affordance |
Scenario question pattern
“A company needs a custom UI to capture multi-step onboarding data into custom objects with complex server-side calculations.”
- Custom objects/fields → Model
- Multi-step UI (LWC or Flow screens) → View
- Complex calculations not expressible declaratively → Apex controller services
“Which change updates only the View?” → Lightning page assignment, layout, LWC template styling—not object schema or trigger logic.
Common Confusions to Avoid
- Apex is not the Model. Apex uses the model via sObjects/SOQL/DML.
- Objects are not Views. An object has tab/UI defaults, but the object definition is data model.
- LWC JavaScript is not a substitute for server-side enforcement. Client logic can improve UX; authoritative rules belong in automation/Apex/database constraints where appropriate.
- Triggers vs. LWC. Triggers respond to data events (controller on model); LWC is primarily view with optional client controller behavior.
- “Salesforce is MVC” does not mean you must reinvent frameworks—it means you can map features to layers for design and exam answers.
Component Architecture + MVC Together
Modern Lightning apps are component trees:
- App page hosts components (composition).
- Each component may bind to Lightning Data Service or Apex.
- Events (or other communication patterns) coordinate sibling/parent updates.
When debugging or designing, ask:
- Is the bug in data shape (Model)?
- In rendering or user interaction (View)?
- In rules, orchestration, or server methods (Controller)?
That three-question triage is exactly what MVC mapping trains you to do—and it is the skill the exam probes when it lists platform features and asks which statement is true.
Key Practice Habit
For any requirement, sketch three columns—Model / View / Controller—and place each deliverable before you choose tools. If the View column is full of business rules, move those rules to Flow/Apex. If the Controller column is inventing new entities that should be objects, move them to the Model. This habit improves both architecture and your Platform Developer I accuracy on feature-mapping questions.
In Salesforce MVC mapping, which set of features best represents the View layer?
A developer creates a custom object Warranty_Claim__c with fields and a lookup to Asset. Which MVC layer was primarily extended?
An Apex trigger prevents an Opportunity from moving to Closed Won unless related custom checklist records are complete. Which MVC role does this trigger play?