Really happy to see this link on the front page!

Another great summary, with a nice visual overview of the evolution is by Aviad Ezra[1]. He summarizes an excellent paper by Mike Potel[2] , that introduces the original MVP pattern. Potel's paper convinced me that classic MVC is almost never applicable in today's "Widget"/"Component" UI paradigms. Perhaps video games where direct control of user input is a first class concept is a place where classic MVC still works.

The separation between the View and ViewModel was introduced to increase the testability of the UI without involving a usually hard-to-test UI framework.

Question: Are there any MVPVM SPA frameworks? The closest I can think of is Backbone.Marionette.

[1] http://aviadezra.blogspot.de/2007/07/twisting-mvp-triad-say-... [2] http://www.wildcrest.com/Potel/Portfolio/mvp.pdf

MVP _is_ huge (probably de-facto pattern) in the Google WebToolkit community.

The way I see it is this: MVC works for Widget level (imagine a Swing component: JTable or something, there's the table rendering => View, the table data => Model, the table event processing/logic => Controller). But you need a higher-level architecture that controls everything in the app and that's where MVP comes in.

There's no framework per-se in GWT because MVP is so easy to implement.

View v = new ViewImpl(); // usually View is an interface or you can mock it...

Service s = new ServiceImpl(); // usually Service is an interface, or you can mock it...

Presenter p = new Presenter(service, view, models);

// in constructor

v.addListener(new Listener(){ public void execute(){ p.processData(); };});

p.getData(); // potentially calls service ajax request

p.persist(); // calls s.persist(model);

p.processData(); // potentially called by the event listener from the view, say user press a button

The idea of MVP is to be able to write unit-test (against the Presenter) that does not touch the widget level but able to cover everything else. Attaching a listener to ensure a code will be executed is considered "configuration".

This MVP style differs to the one mentioned in the Ezra blog where the model calls Repository/Service. This MVP styles makes it explicit for Presenter to orchestrate the Model, View, and Service interaction. No two way binding or implicit stuff.

Nice article from Aviad Ezra, IMO much much better than what Fowler wrote. Especially the "Still confused" which clarifies the confusion between MVC and MVP and "To MVP or not to MVP", where he mentions that the view and presenter can in fact be merged.

Can you elaborate on why MVC is not appropriate for UI's? Currently learning AngularJS and feels like they did a pretty good job of implementing MVC via the $scope interface.

MVC has become meaningless after being overloaded so many times. I looked at the Wikipedia definition and to my surprise I saw that it's significantly different to the one I read, with no mention of the word "input".

Seems that MVC nowadays means MVP (i.e. Model view presenter where the view, presenter and model are layered and comunicate strictly to the layer above and below).

In a way this is good, because MVP works and is used by most UI frameworks, even if they call the "P" "C" in the docs.

I've been living for over 10 years in an industry that has espoused the importance of "MVC" for and I still don't really know what it means.

The original article was kind of confusing on this matter--though that could be a result of me reading it right after I woke up (morning ritual: read HN for half an hour, then get out of bed). I find the Wikipedia page easier to understand [0].

And realize now that whatever I've always been doing and whatever I've seen done on all projects I've been involved on has strictly been MVP, not MVC.

I find these statements to be at odds with each other:

> The model directly manages the data, logic and rules of the application

And then shortly after:

> Whenever there is a change to the data [the model] is updated by the controller.

I know every project I've worked on has interpreted that last statement to mean the model is dumb, that the model does not do anything of its own to manipulate data. Of course, that flies in the face of how they have all ended up getting implemented: relational databases with a significant number of stored procedures.

When you're dealing with RDBMSes, there is a big struggle at play between correctness and performance. And there are no strict answers, everything is dependent on the particular situation. You have to profile everything, because it's nearly impossible to predict how anything will perform before trying it. And it can be a big deal, the difference between sub-second processing in one way and over-a-day the other way. It can be ludicrously bad, so you are guaranteed to be compromising "correctness" at several points in time.

One way I've seen that happen is with a heavy use of stored procedures plus "logic layers". There are stored procedures for getting the data out of the database, but then there is a lot more application-level logic for further manipulating the data into its final form. But often--especially any data manipulation that has no linear dependence between records--the most performant solution is to implement the entire logic in a stored procedure. And that would mean that the store procedures the real controller.

But god daaaaammit, every procedure SQL extension in existence right now is complete garbage as an application language.

The more I think about it, the more I suspect MVC is meant to have the controller have only a notional understanding that "data must change", sending the minimum data necessary to the model to make that change happen, but have the model fully implement that change on its own. This is the opposite of the projects from my past: instead of a "dumb" model, it's a "dumb" controller.

But SQL is far too dynamic for my tastes. I want static checking. I want to be able to test at least the validity of the logic (i.e. "yes, a column named 'Something' really does exist. No, there is no 'Soemthing' column. Yes, you can those two columns together and expect an integer out of the deal.") before ever having to even setup a database server and running it.

What I really want is a strictly-typed language with first-class support for set and relational operations that can be used to validate the query logic before transpiling down to platform-specific SQL. LINQ to SQL was supposed to be that, but in the end I think it missed the boat on a lot of static checking opportunities. Entity Framework is supposed to be that, but it runs on SQL Server only [1], the performance can be bad, and the overall design and workflow seem very inflexible. There are other systems that are mostly built on C#'s `dynamic` keyword. And they all are built under the guise of hiding SQL away from the developer, thus wedging themselves firmly into object-relation impedance mismatch problem.

[0] https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93con...

[1] There are hacks to get EF working on other databases, but they are a pain and it isn't first-class.

Ditto, in a decade of UI dev I have never actually implemented MVC or used it. A lot of Apple iOS/Mac books claim that Cocoa is MVC, contributing to the confusion and now there's the JavaScript libraries which also claim to be MVC.

I didn't say that it's not appropriate :) Just that as originally defined, a Controller object intercepts all user input. From the article, "The controller's job is to take the user's input and figure out what to do with it."

Unfortunately, I haven't had a chance to look at AngularJS in depth. But it would be great to compare the various SPA frameworks and see which parts of the classic patterns they adhere to.

I did a presentation last week at my local JavaScript meetup group about why realtime data binding is ideal for single page apps (see http://slides.com/grosjona/realtime#/). It seems I was merely promoting the Observer Synchronization pattern.

It's interesting to see that this pattern existed long before SPAs were a thing.

To be fair, most of this stuff existed before even Javascript was a thing.