
GUI Architectures (2006) - panic
http://martinfowler.com/eaaDev/uiArchs.html
======
currywurst
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-...](http://aviadezra.blogspot.de/2007/07/twisting-mvp-triad-say-hello-to-
mvpc.html) [2]
[http://www.wildcrest.com/Potel/Portfolio/mvp.pdf](http://www.wildcrest.com/Potel/Portfolio/mvp.pdf)

~~~
Negative1
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.

~~~
blub
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.

~~~
moron4hire
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...](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller)

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

~~~
blub
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.

------
jondubois
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#/](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.

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

