2.2 MVC Mapping on the Lightning Platform

Salesforce Certified Platform Developer I Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Blueprint Weights & Study Strategy

2 Platform Fundamentals

2.1 Multi-Tenant Architecture & Shared Resources 2.2 MVC Mapping on the Lightning Platform 2.3 Declarative vs Programmatic Decisions 2.4 Agentforce for Developers: Use Cases & Limitations

3 Data Modeling & Schema

3.1 Objects, Fields & Schema Design 3.2 Relationship Types & Implications 3.3 Schema Design Impact on Apex 3.4 Data Import & Export for Development

4 Platform Data Features

4.1 Formula Fields & Roll-Up Summaries 4.2 Core CRM Objects & Standard Schema 4.3 AppExchange Extensions & Platform Boundaries

5 Declarative Process Automation

5.1 Record-Triggered Flows & Declarative Automation 5.2 Approval Processes & Business Rules 5.3 When to Use Apex vs Declarative Tools

6 Apex Language Basics

6.1 Variables, Constants & Apex Data Types 6.2 Lists, Sets & Maps 6.3 Control Flow & Exception Handling 6.4 Classes, Interfaces & OOP Patterns

7 SOQL, SOSL & DML

7.1 SOQL Query Fundamentals 7.2 SOSL Search Fundamentals 7.3 DML Operations & Bulkification 7.4 Governor Limits & Transaction Boundaries

8 Apex Triggers & Order of Execution

8.1 Trigger Structure & Context Variables 8.2 Bulk Trigger Patterns & Best Practices 8.3 Save Order of Execution 8.4 Recursion, Cascading & Transaction Control

9 Asynchronous Apex

9.1 @future Methods 9.2 Queueable Apex 9.3 Batch Apex 9.4 Schedulable Apex & Job Orchestration

10 Security, Events & Schema Access

10.1 Sharing, FLS, CRUD & Injection Prevention 10.2 Platform Events Publish & Subscribe 10.3 Programmatic Schema Access (Describe)

11 Visualforce

11.1 Visualforce Pages & Markup 11.2 Standard, Custom Controllers & Extensions 11.3 Visualforce in Lightning Experience

12 Lightning Components

12.1 Lightning Component Framework Benefits 12.2 Aura Component Structure & Resources 12.3 Lightning Web Components Fundamentals 12.4 LWC Data Access: Wire, Imperative & Events

13 UI Composition & Apex Integration Patterns

13.1 Composing UI in Lightning Apps 13.2 UI Security, Performance & Accessibility Patterns 13.3 Apex Actions for Flow, LWC, and Agentforce

14 Apex Testing

14.1 Testing Framework & Coverage Requirements 14.2 Writing Unit Tests for Triggers & Classes 14.3 Test Data Strategies & Isolation 14.4 Executing Tests & Execute Anonymous Differences

15 Debugging & Developer Tools

15.1 Debug Logs & Monitoring 15.2 Developer Console, CLI, VS Code & Workbench 15.3 Sandboxes, Scratch Orgs & Environment Strategy

16 Deployment & Release

16.1 Change Sets & Metadata Deployment 16.2 Unlocked Packages, Metadata API & Salesforce DX 16.3 Release Readiness & Credential Maintenance

2.2 MVC Mapping on the Lightning Platform

Key Takeaways Explain This Topic AI

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

Last updated: August 2026

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__c and Warranty_Claim_Line__c with 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.