
Model-View Catharsis - puzzlingcaptcha
http://acko.net/blog/model-view-catharsis/
======
noelwelsh
I had the impression that much time and thought went into this post but
unfortunately I couldn't make it much past the beginning. I think I'm not much
interested in mixing reading for pleasure and reading for learning, and when
I'm reading for learning I just want to the post to get to the point.

~~~
toomim
I had the same experience. I ended up bookmarking the site, thinking that I
could reference it the next time I wanted to formulate an argument about the
problems with MVC.

It would help to have a conclusion or abstract somewhere, listing the main
points that the article makes, so that I have a way to know where to invest my
attention when reading it.

------
mntmoss
I have to agree that it's a difficult read, and I'm someone who has done a
fair share of looking at these different architectures.

But the broad-strokes recommendations seem approximately like these things I
would say(which are not exactly the things the author says):

* Some things are best done in an incremental fashion rather than a big "update"

* You often need to copy state in your UI code

* It helps to focus on building explicit synchronization points(which I turn to FSMs to do)

* Modelling abstract cursors on data is a helpful UI idiom

------
digitaltrees
I had trouble following due to the cloud of snark and attempted wittiness.

------
z3t4
The MVC pattern is basically what you end up with a naive implementation of a
GUI interface. A more sophisticated solution is the plugin pattern where
independent code can "plugin" by for example listening on events. It's kinda
like MVC but backwards, instead of a button updating the view, the plugin/view
listens for button-clicks. And if a server is involved, the view/plugins
should listen for events sent by the server. Where each little
plugin/component do it's own thing independently. If you for example have a
"new messages" badge that shows _both_ new messages and new chat messages, it
should listen for new messages and new chat messages!! versus the spaghetti-
strategy of having both the messages model/widget _and_ the chat model/widget
update the new-messages widget.

~~~
heavenlyblue
Yeah, and that’s why most of the message passing interfaces struggle with race
conditions.

------
gumby
In addition to the tone it was distracting that as I read images would appear
_behind the text_.

I'm actually interested in principled criticism of weaknesses of the MVC model
(I've been a fan for decades). Anybody have a good link?

~~~
Marazan
The criticism is pretty succinct:

1) No one agrees about what the Controller does 2) As a result no one knows
what should make up the Model 3) Therefore this leaves the Views in a real bad
state

~~~
gumby
Thank you for extracting that!

I don't know about the component state on the web, but from my perspective I
think that is backwards. As I said I'm not a web developer, but for me those
terms are meaningful this way:

Assume I have a program for designing aircraft jet turbines.* It uses a
parametric model that lets you specify shaft length, blade length, combustion
chamber camber, etc. It has its own constraint system that doesn't let you put
10 meter blades in a 4 meter diameter housing. Etc. I have a whole little set
of operations (these days called a DSL) that allow a programmer to manipulate
the model using the vocabulary, metaphor, and mental models of a typical jet
turbine designer.

That is the _M_ in MVC.

I also have a library of routines for drawing parts of the turbine on the
screen. They themselves are parametric with orientation, zoom, etc. A set of
view parts -- the _V_.

Finally I write a little window that displays a turbine with some mouse
gestures and the like that allow me to zoom, rotate etc. Maybe point and ask
questions.

You might write a different program that does the display on an ipad, calling
from my set of Views to fit your interaction model. You won't necessarily need
to know much about turbines, frankly, as my model should give you all the
affordances you need.

==

After reading your great note, I went and read a bit from the article and it
seemed that the author is entirely in the display -- in the "C". Elements like
a user name (let's say a part number in this example) aren't so much as model
items -- high level abstractions, but simply inputs. To me the model is the
program domain model. To be forced to take the same approach with mere UI
widgets is cruelty indeed, and perhaps _that 's_ the author's argument?

* obviously nobody would write such a program this way; this is expositional

~~~
qznc
I believe it is not worthwhile to treat MVC as a pattern to emulate:
[http://beza1e1.tuxen.de/model_view_controller.html](http://beza1e1.tuxen.de/model_view_controller.html)

------
ambicapter
So the writing is really ornate but one thing that stood out to me

> 1px wide gradient edge

wtf is a 1 pixel gradient?

~~~
mistrial9
1 pixel gradient is an old games/graphics trick.. Define an array of pixels,
but only one "row".. match the length of the array to the dimension desired,
then use the graphics primitives in the window to stretch and fill.. (here, a
picture is worth a thousand words) think of a To-Be-Defined rectangular area,
and a gradient that is mapped to either the x or Y dimension, and "stretched"
across to make the rectangular fill.

