MVC

Separates the model (data), view (UI), and controller (input) into independent components.

Context

The classic architecture for UIs and most web frameworks (ASP.NET MVC, Rails, Spring MVC).

Solution

Model: data and rules.
View: render.
Controller: receives input, calls the model, chooses the view.

public class OrdersController : Controller
{
    private readonly IOrderService _svc;
    public OrdersController(IOrderService s) => _svc = s;

    public async Task<IActionResult> Detail(Guid id)
    {
        var order = await _svc.GetAsync(id);
        return View(order);                  // ← Razor view receives the model
    }
}

When NOT to use it

In SPAs: the backend controller no longer controls the view. Consider MVVM or Backend-for-Frontend.

#Where it is used

Server-side web with views rendered on the server (ASP.NET MVC, Rails, Spring MVC, Django in its MTV variant). For apps with persistent UI state (mobile, desktop), MVVM is usually a better fit.

MVC is a presentation pattern, not a whole-application one. A fat controller with business logic is the most common mistake: business rules belong in Application/Domain, not in the controller.

#architecture #ui