Lesson 2 of 30

Data Layer vs Design Layer: MV* Architecture

Q: What problem does separating a 'data layer' from a 'design/view layer' actually solve, and what breaks in a large codebase if you don't?

A strong answer covers: The data layer owns what the data is and how it changes; the view layer owns how it's displayed; Keeping them separate lets data logic be tested without a browser or UI, and reused across different UIs; Without separation, a large app becomes hard to test, hard to reuse, and UI changes risk breaking tangled data logic.

Q: A large team's app lets any component directly mutate a big shared global object whenever it wants. What goes wrong at scale, and how does something like Redux's unidirectional flow fix it?

A strong answer covers: With direct mutation from anywhere, tracing which component caused a given state change becomes very hard as the app grows; Unidirectional flow forces every change through one reducer, reached only via a dispatched action — every change is traceable to a specific action; Components can request a change but can't mutate the store directly — the same read-only-from-child rule from props, applied app-wide.

Why big apps separate 'what the data is' from 'how it looks' — and how that one idea shows up as MVC, then Flux/Redux, then React's own one-way data flow.

14 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

Why can `fetchUsers()` in the separated example be tested with no browser at all, while the tangled `loadAndShowUsers()` version can't?

fetchUsers has no DOM dependency at all — it's pure data logic, unlike the tangled version which directly manipulates the DOMfetchUsers doesn't actually call fetch, so there's nothing to testTesting frameworks can't run any code that uses async/await

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Data Layer vs Design Layer: MV* Architecture

What interviewers actually ask about this, and what a strong answer has to cover.

What problem does separating a 'data layer' from a 'design/view layer' actually solve, and what breaks in a large codebase if you don't?

A strong answer covers

The data layer owns what the data is and how it changes; the view layer owns how it's displayed
Keeping them separate lets data logic be tested without a browser or UI, and reused across different UIs
Without separation, a large app becomes hard to test, hard to reuse, and UI changes risk breaking tangled data logic

Likely follow-ups

Where does React's own useState and one-way data flow fit into this — is a React app already following this separation, or does it need something extra like Redux?
What's the actual definition of the 'C' in MVC — what specifically is a Controller responsible for?

A large team's app lets any component directly mutate a big shared global object whenever it wants. What goes wrong at scale, and how does something like Redux's unidirectional flow fix it?

A strong answer covers

With direct mutation from anywhere, tracing which component caused a given state change becomes very hard as the app grows

The plain-language idea

MVC (Model–View–Controller) is the classic answer to one problem: keep "what the data is and how it changes" (Model) separate from "how it's displayed" (View), with something (a Controller) deciding what happens in response to input. The exact shape has changed a lot since — MVVM, Flux, Redux — but every variant is solving the same problem: don't let display logic and data logic become the same tangled thing.

You've already seen a version of this: props's one-way data flow (data down, changes only via a callback) is this exact idea, applied to one component. Flux/Redux apply it to an entire app's shared state.

See it in a real thing: tangled vs separated

// ❌ tangled: fetching, deciding, and rendering are one blob
async function loadAndShowUsers() {
  const res = await fetch("/api/users");
  const users = await res.json();
  document.querySelector("#list").innerHTML = users
    .map((u) => `<li onclick="deleteUser(${u.id})">${u.name}</li>`)
    .join("");
}

// ✅ separated: data layer and view layer don't know about each other
async function fetchUsers() {              // data layer
  const res = await fetch("/api/users");
  return res.json();
}

function renderUserList(users, onDelete) {  // view layer
  return users.map((u) => `<li data-id="${u.id}">${u.name}</li>`).join("");
}

fetchUsers can be tested with no browser at all — it's just a function returning data. renderUserList can be tested by handing it fake data — it never has to know where that data came from. Neither can break the other.

Model-View: data that knows nothing about its displayStep 1 of 3

Model: the data and business logic — knows nothing about how it's displayed.

What people usually miss

Watch out

"MVC" in a frontend interview rarely means the strict, original 1970s definition. React doesn't have a distinct "Controller" — event handlers and reducers took over that role. Interviewers usually want to see you understand the underlying separation, not recite the original three letters.
Flux/Redux's unidirectional flow exists specifically to make big apps debuggable. If any component can mutate shared state directly, "who changed this and why" becomes untraceable as the app grows. Forcing every change through one reducer, reached only via a dispatched action, means every state change has a name and a single choke point to log through.
This is the props lesson's rule, at a bigger scale. A component can't mutate its own props — it calls a function the parent gave it. Redux applies the identical rule app-wide: a component can't mutate the store — it dispatches an action, and only the reducer is allowed to produce the new state.
More structure isn't free. A small app with a couple of components doesn't need Redux's ceremony — the tradeoff is real: more structure buys traceability and testability at the cost of more boilerplate for simple cases.

Why this matters in interviews

"How would you structure a large app's state?" tests whether you understand why the separation exists — testability, debuggability, and reuse — not whether you can name MVC's three letters. Tying it back to the one-way data flow you already know from props is what shows real understanding instead of memorized vocabulary.