Why do backend web frameworks use "MVC" when they have no persistent UI to update?

Question

Model View Controller (MVC) is focussed on UI based applications. In MVC the model notifies the UI (view) when its values change and the view then decides what and if to update. I can understand this for desktop, mobile and single page web applications where there is a persistent UI.

But why do some popular backend web frameworks such as ASP.Net Core, Ruby on Rails, Django etc use MVC when there is no UI to update, once the templated page view is rendered and returned? Once it has has finished rendering the page, the backend is not responsible for updates to the UI.

For example, ASP.Net Core refers to models as simple data structures without methods on them, that map to entities in e.g. a database. For example:

using System;
using System.ComponentModel.DataAnnotations;

namespace MvcMovie.Models
{
    public class Movie
    {
        public int Id { get; set; }
        public string Title { get; set; }

        [DataType(DataType.Date)]
        public DateTime ReleaseDate { get; set; }
        public string Genre { get; set; }
        public decimal Price { get; set; }
    }
}

Is there something I am misunderstanding about MVC, or is the term used quite loosely in this case?

Answer 1

The MVC design pattern was initially developed before the Web was a thing. It mainly addressed architectural problems that applications with a richly interactive GUI had. The main benefit was Separation of Concerns. Something had to handle business logic and persistent data storage (the "Model"). Something had to handle the presentation of the use case to the end user (the "View"). And something else had to coordinate the use case and initialize the whole thing (the "Controller').

It was determined that events were the ideal medium of communication between these three components, because it decouples the Model, View, and Controller. You will find that "decoupling" and "Separation of Concerns" are complimentary concepts. In fact, you really cannot "separate your concerns" without decoupling components. This is crucial to understanding why web frameworks, which have no persistent user interface, continue to use this design pattern. Don't get too hung up on events and persistent user interfaces. Events were an artifact of building an application with a persistent UI rather than being the foundation of the MVC design pattern.

Even though the Web has a stateless UI, it is still desirable to separate business logic (the "Model"), presentation logic (the "View"), and use case coordination logic (the "Controller"). Since the Web has a stateless user interface, events are replaced with HTTP requests — an artifact of building an application with a stateless user interface. The main benefit of the MVC design pattern is separation of concerns. This is still realized on the Web, regardless of how the UI is implemented.

---

As a side note, Microsoft's first widely-used web framework (ASP.NET WebForms) attempted to literally turn HTTP requests into application events. A hidden form field on each page contained a serialized version of the "view state". Upon POSTing back to the server, the view state was rehydrated from this serialized form field. Then based on the name of a button, the framework would trigger a simulated UI event just like you would expect from a persistent user interface. The framework attempted to hide the messiness of a stateless UI for people already familiar with MVC in desktop applications. It turned out to be a leaky abstraction, though.

Answer 2

Again, I had it wrong originally, updated, and still might contain stuff wrong, If someone can write a proper answer I'm all for it.

Okay, so I had it wrong. Updated:

THE MVC

• The Model is the background bussiness logic used to work with the data, it can contain the ORM model you have in your example many other things
• The Controller is the class doing something with The Model and producing Data Transfer Object or ViewModel and passing it to the View
• The View uses the Data Transfer Object/ViewModel to present itself

The MVVM

• The Model is the background business logic used to work with the data, it can contain the ORM model you have in your example (same as MVC)
• The ViewModel is the class doing something with The Model and populating data structures (properties) in itself. Then there is something listening (for simplification and because I'm lacking proper knowledge too, let's call it a view)
• The View reacts to the event, looks at the ViewModel property that changed, and draws/updates itself