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.