3

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?

5
  • 2
    because the pattern still works even if you regenerate the view every request.
    – Ewan
    Jun 24 at 8:35
  • But isn't the "model" in these frameworks strange? There aren't supposed to have methods on them, for example. It doesn't have to notify the UI of changes so that's fine in that regard.
    – Eoin
    Jun 24 at 8:53
  • 2
    I think you're looking too hard into this. In MVC, the general idea is that there is a controller that does something and in the end, produces a model that is given to a view (thus "MVC") that presents itself using the model data. The database entities are models, but not (or at least should not be) "MVC" models, they are models for ORM (obejct relational mapping) like entity frameworks. They are NOT MVC models.
    – mishan
    Jun 24 at 9:02
  • 5
    The model in MVC can be anything, it does't have to be an ORM entity model as in the example. But for simple CRUD applications, the model is often ORM entities, so you will se that a lot in tutorials and examples.
    – JacquesB
    Jun 24 at 9:24
  • Thank you JaquesB, that cleared it up for me. Seeing two types of model in apps with/ without an ORM was confusing me.
    – Eoin
    Jun 24 at 10:51
2

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.

1
  • Thank you, this helped my understanding a lot. It was confusing to use front-end frameworks like Angular which focus on MVC with models emitting events, to then switch to the back-end and have models either be an ORM entity or data access class. Now it makes sense to me. Your history of ASP is also very insightful.
    – Eoin
    Jun 26 at 10:55
4

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
3
  • Thank you mishan, that cleared some confusion up for me. Also for your explanation of MVVC vs MVC.
    – Eoin
    Jun 24 at 10:50
  • @Eoin I edited the answer, as I had some of the knowledge wrong
    – mishan
    Jun 24 at 13:12
  • Ahh, okay. I will update the answer (again) then. :)
    – mishan
    Jun 24 at 14:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.