Rediscovering MVC | Hacker News Reader

Rediscovering MVC

github.com

92 pointsinsin18 comments

I love that this was posted at almost the exact same time as https://news.ycombinator.com/item?id=10740029

Weird, I actually posted this yesterday morning - the Firebase API shows the correct time: https://hacker-news.firebaseio.com/v0/item/10730047.json?pri...

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

Probably the moderators reset the submit time of your post because they wanted it to compete with that other post.

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.

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 ?

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?

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

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.

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."

Meh. If there is a doubt, call it "Observer pattern" instead. But I understand where you are coming from. Most mobile apps with a RESTful back-end don't even implement an end-to-end observer pattern properly.

Many times I see the tryptic: Input, Logic, Output

  - MVC
  - REP[L]
  - * I forgot the other ones *

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.

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.

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.

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

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

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.

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. :)

Reply on news.ycombinator.com