Model–view–controller Study Guide

📖 Core Concepts Model–View–Controller (MVC) – Architectural pattern that splits an application into three loosely‑coupled parts: Model (data & business rules), View (visual representation), Controller (user‑input handling). Model – Central component that owns the dynamic data structure, enforces business logic, and is independent of any UI. In most frameworks it maps directly to a database table. View – Renders model data (HTML, charts, tables, etc.). A view can be composed of sub‑views and many views may present the same model simultaneously. Controller – Receives user actions, validates them, and translates them into commands that modify the model or trigger view updates. Variants – Hierarchical MVC, Model‑View‑Adapter, Model‑View‑Presenter, Model‑View‑ViewModel; each adapts the core idea to a specific context (e.g., richer client‑side data binding). Thin‑Client Server‑Side MVC – Entire MVC stack runs on the server; the client only sends requests (links/forms) and receives a fully rendered page. Hybrid Client‑Server MVC (Ajax) – Parts of MVC live on the client; Ajax calls keep client‑side views in sync with server‑side models. --- 📌 Must Remember Separation of concerns is the heart of MVC: data, presentation, and input are independent. Multiple independent views can display the same model at once → flexible UI designs. Controllers never render UI; they only coordinate model updates and view refreshes. Early web MVC placed all logic on the server; modern frameworks often split logic between client and server. Reusable sub‑views let complex interfaces be built from smaller, composable widgets. --- 🔄 Key Processes User Interaction → client sends event (click, form submit) to Controller. Controller validates input → decides which Model operation to invoke. Model updates its state (create, read, update, delete). Model notifies all registered Views that its data changed. Each View pulls the latest data from the Model and re‑renders itself. Rendered output is sent back to the client (full page in thin‑client MVC or partial HTML/JSON in Ajax‑enabled hybrid MVC). Hybrid Ajax flow adds an extra step: after step 3, the server returns a JSON payload; client‑side JavaScript updates the client model, which then triggers the client view to re‑render without a full page reload. --- 🔍 Key Comparisons MVC vs. Model–View–Presenter (MVP) MVC: Controller mediates input → model; view pulls data from model. MVP: Presenter receives input, directly updates the view; view is passive. Thin‑Client Server‑Side MVC vs. Hybrid Client‑Server MVC Thin‑Client: All three components live on the server; each request returns a complete page. Hybrid: Controller and model stay server‑side, but the view (or part of it) runs in the browser and syncs via Ajax. Model–View–Adapter vs. Model–View–ViewModel Adapter: Adds a thin translation layer between model and view. ViewModel: Exposes model data as bindable properties, enabling automatic UI updates. --- ⚠️ Common Misunderstandings “The model automatically redraws the UI.” The model notifies views; each view must actively fetch data and re‑render. “Controllers render HTML.” Controllers only coordinate; rendering is the view’s job. “MVC is only for desktop GUIs.” MVC was invented for GUIs but is now a standard pattern for web apps, mobile, and even APIs. “A view can modify the model directly.” Direct model mutation bypasses validation and business rules; always go through the controller (or a service layer). --- 🧠 Mental Models / Intuition “Bank, ATM, and Customer” – Think of the Model as a bank vault (stores money), the View as the ATM screen (shows balance), and the Controller as the teller (accepts the customer’s request, checks it, and updates the vault). “Three‑way conversation” – User talks to the controller, the controller talks to the model, the model talks back to the view, and the view talks back to the user. --- 🚩 Exceptions & Edge Cases Variant selection – Use MVVM when you need heavy two‑way data binding (e.g., modern front‑end frameworks). Client‑side only MVC – Some single‑page apps push the entire MVC stack to the browser; server only supplies an API. Multiple Controllers – Complex apps may have a controller per UI region rather than a single “master” controller. --- 📍 When to Use Which Thin‑Client MVC → Simple sites, SEO‑critical pages, or when you want full‑page refreshes for each interaction. Hybrid MVC with Ajax → Interactive dashboards, real‑time updates, or when you want a smoother user experience without full reloads. MVVM → Projects built with frameworks that support declarative data binding (e.g., Angular, Knockout, Vue). MVP → When you need a very testable UI layer and the view should be completely passive. --- 👀 Patterns to Recognize “Same model, many views” – Look for multiple UI components (list, chart, table) all pulling from one underlying data source. “Controller → Model → Notification → View” flow in code snippets. Ajax‑based update pattern: POST /api/... → server updates model → returns JSON → client view refreshes. Sub‑view composition: A parent view contains child views, each responsible for a portion of the UI. --- 🗂️ Exam Traps Distractor: “The controller renders the final HTML.” Why wrong: Rendering belongs to the view; the controller only directs flow. Distractor: “Models can contain UI code.” Why wrong: Models must stay UI‑agnostic; UI belongs in the view. Distractor: “MVC only applies to desktop applications.” Why wrong: MVC is widely used in web, mobile, and API design. Distractor: “In a hybrid MVC app, the server never touches the view.” Why wrong: Server‑side views may still generate initial HTML; only parts are updated client‑side via Ajax. ---