Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MVC Isn’t MVC

collindonnell.com

Post reply on HN
Print view View original

31–40 of 165 posts

Re: MVC Isn’t MVC

#31

Post by derefr »

So, the original MVC was designed in the context of green-screen terminal systems. In that context, this “design pattern” really isn’t a design pattern per se; it’s just a formalism over the code you’d inevitably write to make such a system work. In a green-screen system:

• the “view” is the terminal buffer state — not even a “virtual DOM” version of it, but literally the buffer state itself (under 3270 protocol, properties like “editable” are basically bits in the TTY buffer applied per-cell — you can think of them like ANSI TTY-cell background colors and not be far off.) Think of it as an mmap(2)ed file in backend memory, holding structs of almost the same type as the view, save for OS-syscall-time remapping to prune out the form labels.

• the “model” is the ADT over the record-oriented mainframe datafile backing the terminal (How does the model know how to change the view? Because it’s a very thin abstraction: fields in the view-state, and fields in the DB state, are 1:1, with no parsing or serialization — leading to things like passwords only being stored in the DB at the size of the form-field for them.)

• the “controller” is the serial line-discipline that interprets the key codes sent from a TTY into editing actions like “overwrite a character” or “backspace”, and applies those actions to the data in the model (how does it know what part of the model is active? “Spatial databases” have something like a hierarchical navigation-path DB cursor as part of their descriptor state. Switching the active view is a model state change!)

• you need an “editor” separate from the “controller” because otherwise every character edit action sent to the TTY would provoke an instantaneous commensurate change in the DB data. If you need to store and validate live edits before committing them to the DB, then you need an editor “proxy” object to hold that “draft” state.

All in all, pretty different from anything we’re doing these days. Or is it? Depends on where you draw the line of abstraction! In modern terms:

• the classical MVC “controller” is the frontend or per-component view controller — observing the client’s actions and feeding them into the system as events.

• the classical MVC “view” is the API query result set, databound through the client DOM components. If your app is server-side rendered, it’s the HTML DOM itself as loaded into the browser!

• the classical MVC “model” is the entire backend, through its API

• the classical MVC “editor” is the changeset — a CQRS Command-in-draft. (In a HATEOAS context, an HTML form is also this.)

Re: MVC Isn’t MVC

#32

Post by LudwigNagasena »

> Model updates View, View sees User, User uses Controller, Controller manipulates Model.

> This makes a lot of sense to me, and I think I understand it pretty well.

It looks simple at first glance, but it actually makes zero sense under closer inspection.

Let’s take a simple example. A table of users. You take a table from the database and put it into an html tag table. Wait, who is “you”? The model? Do you want your model to know about html? The view? Do you want your view to know how to connect to a db? The glue code for them? If so, then it is the model-view-controller-glue, not model-view-controller.

This is why what the author calls Apple-MVC is far more common. It is just hexagonal architecture. You take different components that take care of their own area of concern and glue them together to fit specific needs of your app. That glue code is called “controller” in that case. It is intuitive and simple; and thousands of junior developers probably reinvent that type of architecture every day.

Re: MVC Isn’t MVC

#35

Post by gumby »

derefr wrote: post #31

So, the original MVC was designed in the context of green-screen terminal systems. In that context, this “design pattern” really isn’t a design pattern per se; it’s just a formalism over the code you’d inevitably write to make such a system work. In a green-screen system: • the “view” is the terminal buffer state — not even a “virtual DOM” version of it, but literally the buffer state itself (under 3270 protocol, pro…

> So, the original MVC was designed in the context of green-screen terminal systems.

Not at all: this was designed at PARC in the context of the Alto and the D machines running systems like Smalltalk. It even mentions the mouse. It talks about querying the type of a field, that might for example contain text.

You reasonably mapped it to a serial character terminal but this is not at all what it was designed for.

Re: MVC Isn’t MVC

#36

Post by derefr »

gumby wrote: post #35
derefr wrote: post #31

So, the original MVC was designed in the context of green-screen terminal systems. In that context, this “design pattern” really isn’t a design pattern per se; it’s just a formalism over the code you’d inevitably write to make such a system work. In a green-screen system: • the “view” is the terminal buffer state — not even a “virtual DOM” version of it, but literally the buffer state itself (under 3270 protocol, pro…

> So, the original MVC was designed in the context of green-screen terminal systems. Not at all: this was designed at PARC in the context of the Alto and the D machines running systems like Smalltalk. It even mentions the mouse. It talks about querying the type of a field, that might for example contain text. You reasonably mapped it to a serial character terminal but this is not at all what it was designed for.

I said “in the context of”. As in, Smalltalk itself was designed in an environment where green-screen terminals were a recent and popular paradigm. As such, in some ways, they’re reflections of one-another: isomorphic solutions to problems the same people were having around the same time.

Also: IBM 3270 protocol is not a “serial character terminal” protocol. It’s essentially an X11-like client-server bidirectional state synchronization protocol for what are essentially pure-text HyperCards.

If you can understand that, then you can probably see how Smalltalk is — in the abstract! — a green-screen terminal system. (So is X11 itself; and so are modern “framework display server protocols” like QML and XAML; and Mozilla’s XUL; and of course HTML.) Smalltalk just happens to have the client and server in the same address space. (But they’re still separate objects — a Smalltalk display window is a “control” that doesn’t share state with its backing delegate that’s telling it what to display.) One could think of this as the “client - backend responsibility separation” paradigm. It originated in the offices of people trying to horizontally scale out interactions.

This is in contrast to the libtermcap/ Windows GDI / bitmap-buffer bit-blit approach to view-state management, where there is a presenter that is a kind of “driver” for the model, living subordinately embedded inside its address space and synchronously “rendering out” whatever the model decides to render. This paradigm originated in single-tasking microcomputers.

Re: MVC Isn’t MVC

#37

Post by roncesvalles »

MVC is one of those things (like Agile) that doesn't actually mean anything and people just nod their heads and gloss over it when someone mentions it.

You know when something is that kind of thing when most discussion on it is about the definition.

Re: MVC Isn’t MVC

#38

Post by jfengel »

strken wrote: post #28
bsaul wrote: post #9

Not sure why author got the impression apple’s models had to be « dumb data containers ». Actually, having dumb models is the surest way to completely screw up your controllers design, since you’re now left with no other places to write your business logic in. This leads to either weird trees of controller inheriting each other for the sake of reusing some data processing piece, or singletons everywhere which makes t…

> My take on the model layer is : write everything that’s not strictly specific to your UI there. My take is this, except with the caveat that the larger a model gets, the closer to declarative it should become. You touched on this by saying the model layer rather than just the model, but it's worth emphasising. You can achieve this by abstracting out the messy bits, e.g. moving some hooks to a task queue (processing…

Heh. "500”. I have had monsters ten times that size.

And yet it wasn't obvious that refactoring was really an improvement. Sometimes the program is just big and does a lot of things.

It's not good. It's a disaster waiting to happen. And yet until it does the code smell can continue to smell without strangling anybody.

Re: MVC Isn’t MVC

#39

Post by deeviant »

derefr wrote: post #31

So, the original MVC was designed in the context of green-screen terminal systems. In that context, this “design pattern” really isn’t a design pattern per se; it’s just a formalism over the code you’d inevitably write to make such a system work. In a green-screen system: • the “view” is the terminal buffer state — not even a “virtual DOM” version of it, but literally the buffer state itself (under 3270 protocol, pro…

> In that context, this “design pattern” really isn’t a design pattern per se; it’s just a formalism over the code you’d inevitably write to make such a system work.

What exactly do you think a design pattern is?

Re: MVC Isn’t MVC

#40

Post by nightpool »

vsareto wrote: post #27
bsaul wrote: post #9

Not sure why author got the impression apple’s models had to be « dumb data containers ». Actually, having dumb models is the surest way to completely screw up your controllers design, since you’re now left with no other places to write your business logic in. This leads to either weird trees of controller inheriting each other for the sake of reusing some data processing piece, or singletons everywhere which makes t…

We really need to call it Model-View-Controller-Service-Repository and be done with it. That is actually what happens 99% of the time. Logic is done within services and where the complex dependency graphs live. Repositories do the data retrieval. The controller is a traffic cop. The model is a data transfer object with maybe some calculated fields. The view makes things pretty.

No, please for the love of god stop writing services. Having random grab-bags of methods makes it infinitely harder to find what code lives where, instead of putting it into models where we have 20+ years of OO design principles (single responsibility, open to extension, liskov substitution, interface segregation, etc) to guide us. "Fat models, skinny controllers" is a Rails guiding principle for a reason
Post reply on HN