
Rediscovering MVC - insin
https://github.com/ciscoheat/mithril-hx/wiki/Rediscovering-MVC
======
adwmayer
I love that this was posted at almost the exact same time as
[https://news.ycombinator.com/item?id=10740029](https://news.ycombinator.com/item?id=10740029)

~~~
insin
Weird, I actually posted this yesterday morning - the Firebase API shows the
correct time: [https://hacker-
news.firebaseio.com/v0/item/10730047.json?pri...](https://hacker-
news.firebaseio.com/v0/item/10730047.json?print=pretty)

    
    
        >> new Date(1450084080 * 1000)
        Date 2015-12-14T09:08:00.000Z

~~~
vive-la-liberte
Probably the moderators reset the submit time of your post because they wanted
it to compete with that other post.

------
EvanPlaice
Enough with all the 'hand wavy' MVC application already!

MVC had a brief resurgence in the mid 00s with frameworks. So, everybody who
learned web development during that time following MVC (mistakenly) tries to
shoehorn everything into the same mental model.

For example, here's a modern Angular2 SPA + Microservice architecture in terms
of MVC...

Front-End (VCVCM?C?): HTML/CSS + Routes + Templating + Services V C VC M?C?

Backend (N/A): LoadBalancer + Node HTTPD (*N Instances) + Cache + Database ?
See Below ? ?

HTTPD (CMCC): StaticFileAPI + DataAPI + RedirectCatchallAPI C MC C

Altogether that makes this a VCVCM?C?CMCC

It's like devs who learned one OOP language and thing everything in the world
that can't be described in OOP terms is garbage.

OK, so now that I've probably offended both the MVC and OOP crowd. Can we call
this what it is?

Separation of Concerns...

Expand your perspective a bit. Try out a new worldview or two. See if you can
find one where you don't have to 'hand wave' away the details.

MVC only really works to describe self-contained, monolithic, desktop
applications. Even when it was applied to web development, it only really
described the backend server portion and completely ignored the role the
client.

Moral of the Story: Network architectures are inherently complex and multi-
layered. That's what makes them so powerful. With well defined APIs it's
possible to break out of a monolithic application mindset and do very
interesting things.

~~~
mobiuscog
You don't seem to be able to grasp that a 'modern' multi-layered application /
architecture can always be broken down into self-contained 'monolithic'
components.

Which you can apply MVC to. In multiple ways. If you want to use that as a way
of abstracting the concepts.

Maybe you think that input->process->output is too simplistic to be the answer
to every software engineering problem ?

~~~
EvanPlaice
You don't seem to grasp the point of my comment. The format mangling probably
didn't help.

I'm saying that the term MVC has been diluted and misused to the point that it
no longer carries a specific -- and therefore useful -- meaning. It has become
web 2.0 part deux.

Maybe you think that input->process->output is too simplistic to be the answer
to every software engineering problem?

In the most general and abstract terms, no. Likewise, what value is to be
gained from discussing application architecture in excessively general and
abstract terms?

------
voyou
There's an interesting discussion on the Portland Pattern Repository about the
shift in meaning in MVC from the way it was originally used in Smalltalk to
the very different way it's used in most MVC frameworks today:
[http://c2.com/cgi/wiki?WhatsaControllerAnyway](http://c2.com/cgi/wiki?WhatsaControllerAnyway)

~~~
platz
When I hear the Faceboo-React people talk about "MVC", it seems like their
experience of the term is from Native-UI frameworks, especially those with
active Views that call themselves "MVC".

Then we have "Javascript MVC" frameworks like Angular, which have "bindings"
and this makes them MVC.

Then I think about the Server-side web programmers (i.e. Rails) which are also
"MVC" that render the whole response for a request.. the view is often just a
template. This is also "MVC".

Basically the term has completely lost it's meaning at this point.. It's
simply a pejorative term now, because we don't take the time to name/reveal
the particular things we don't like about certain frameworks, we just call
them MVC.

~~~
adrtessier
I agree. I think "MVC" has been abused to the point of where it means "the
insides of this don't look like a PHP app from 2007, where it's function
soup."

------
gitaarik
It looks to me this article is mostly about client side development. As an all
round developer, I usually think about MVC in the backend (server side). Now
that I recently got more into bigger client side applications it does surprise
me there aren't any good MVC kind of libraries/frameworks. To my taste there
isn't any good satisfying way to efficiently manage a lot of data on the
client side.

I'm talking about doing complex querys on your data done through a
sophisticated ORM like that of Django for example. Having relations in your
data instead of having to loop trough all your arrays or doing REST calls all
the time.

In that aspect I think there's still a lot of nice steps to be made in client
side development.

~~~
zachrose
I've been doing client side development for a while, and I do not think MVC
applies cleanly to the browser as it does to a web server.

In the terms of the 1970s breakdown presented in this article, a DOM node is
both a view (presenting information to the user) and a controller (collecting
and forwarding UI events).

MVC is a fine pattern, but underwhelming when taken as an architecture. It
doesn't tell you how state will be managed and reasoned about, which along
with asyncronous sequencing is the main challenge of browser development.
Server side MVC doesn't really have this problem because at the end of they
day the lifecycle of a HTTP request is relatively limited. Most JavaScript MVC
libraries have their own answers for how state should change, but just being
answers does not necessarily make them complete, good, or right for your
application.

My general strategy these days is to avoid parts of my code having to know
that other units are "a Backbone collection" or "a React view", and instead to
have those as implementation details that I wrap in a smaller, more limited
API. Instead of a framework I just use an event bus with a catalog of events
that are very specific to my application. In a way this creates a "data" or
"service" layer that has to fulfill event contracts, which are basically
abstractions over HTTP, websockets, local storage, etc, and a "statically
allocated" view layer that only knows how to respond and trigger a few events
on the bus. You might call that MV and say that the C is somewhere, but to me
that's more confusing than helpful.

~~~
ciscoheat
Very insightful comment, zachrose. At the end of the article I've linked to
DCI, which is the perfect complement to MVC - DCI is an architectural pattern
that separates what the system is (data) from what it does (function), and
mapping the user's mental model directly to code.

When you grasp how it works, things fall into place very well, with no
abstractions, polymorphism or similar things that makes the code divided and
very hard to reason about.

------
hosh
MVC being the user's model, not the programmer's model -- that's a great
insight.

------
newmana
I love this quote from Christopher Alexander, author of Pattern Language on
its failure:

"So there is the slightly strange paradox that, after all those years of work,
the first three books are essentially complete and, from a theoretical point
of view, do quite a good job of identifying the difference but actually do not
accomplish anything. The conceptual structures that are presented are just not
deep enough to actually break down the barrier. They actually do not do
anything."

[https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf](https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf)

------
charlieflowers
Umm, the GoF Design Patterns book was not published in the 80's. Design
Patterns were not all the rage on Commodore 64's and Apple II's.

1994, so well into the 90's decade. OP, if you're reading, this is a big
blunder that takes away from what is otherwise an insightful post.

~~~
ciscoheat
Software design patterns were introduced at OOPSLA in 1987, and were
"immortalized" as the GoF patterns in 90-94. People coded OO in C++ and
Smalltalk all through the 80:s, it wasn't just about the C64 and Apple II. :)

