You know it's nice reading a criticism of something that has an alternative solution offered rather than just going "hey MVC is terrible and you're an idiot for using it".
I do however think there's still great benefits to MVC, if you're shovelling code into controllers and can't make it work like it should then MVC is not the right design pattern for the project. Like every other pattern it'll only work when it works, but MOVE sounds like an interesting addition that I might have a play with.
MVC is terrible for web apps (in the original local GUI domain it's fine for some things), you aren't an idiot for using it because you're probably not actually using it but rather only something loosely inspired by it, and the solution is simply DRY. MVC at its best is simply one manifestation of DRY, but there's no real reason to get too stuck on it when with practice DRY is something you should just always be doing. If MVC falls out of that, great, but if not, so what?
(The original MVC is actually useless for web apps because there is no client-server connection in it, and that profoundly changes everything. There's no point in trying to bash a GUI top-level design into a new client-server world, especially when DRY is just sitting there, waiting for you to use it.)
MVC, MOVE, all the variants just obscure your vision from the underlying and far more important principle.
I suspect this is because most people do not actually understand what MVC is and how it applies to server-client relationships; in fact, the wikipedia article on MVC is slightly off on the subject, assuming one accepts the original Xerox description as a source. Try not to wrap the entire complicated application into one big MVC umbrella because that will just confuse. There are actually multiple processes involved, and each has its own MVC.
The big epiphany for me was when I realized that the server has its own MVC, and the browser has its own MVC. The server's output is the View for the server and the Model for the browser. For a complex set of objects in a given Model, the final output of those objects is their View, and the consumer of that output uses it as a Model. In theory, any View can be a Model for the thing accepting the View, so in a complex system, you have a chain of MVCs.
And one can further imagine that applets written in JavaScript have their own MVC unit.
I work on complicated, large-data web apps sometimes daily. MVC has been a fine model for them and has kept my group's organization clean and modular.
> in fact, the wikipedia article on MVC is slightly off on the subject, assuming one accepts the original Xerox description as a source.
People complaining about factual inaccuracies on Wikipedia annoy me. It's Wikipedia. The entire point and purpose of it is to fix what you know is wrong.
For once, I'd like to see, "I just touched up the Wikipedia article on this subject to explain it a bit more accurately."
This can be a really frustrating experience with articles where most people hold misconceptions about the concepts. I spent a few months off and on on the REST article and managed to clean it up a fair bit, but I was constantly working against militantly ignorant people. Last I checked it's somewhere between accurate and bullshit, one of the poorer resources for understanding either actual REST or more popular RPC style APIs.
>"I just touched up the Wikipedia article on this subject to explain it a bit more accurately."
"But then all my changes were reverted by an overprotective editor; I brought the issues up on the talk page, but my comments were brusquely dismissed."
Your changes would still be in the edit log, and someone more savvy in Wikipedia politics would have the opportunity to get your changes cemented. Said person might be another HN reader who is less knowledgeable about the subject matter.
If you don't make any changes, he has nothing to work with except some random whining.
(And yes, that's how it works in the real world, too.)
The article about MVC on Wikipedia wasn't just slightly off. For a long time, it was completely overrun by people who seemed to think MVC is an architecture for web apps. Real MVC, as the term had been used for decades before the web apps abused it and still is in interactive GUIs today, was all but relegated to a footnote.
"Touching up the Wikipedia article" has little value in cases like this. Usually the only remedy at that point is to delete the entire thing and start again, which somebody finally did not long ago.
>People complaining about factual inaccuracies on Wikipedia annoy me. It's Wikipedia. The entire point and purpose of it is to fix what you know is wrong.
This presupposes
1) I care about fixing it.
2) I have the knowledge to fix it (spotting and removing an inaccuracy is easy, knowing the correct and full set of facts to substitute it with not so much)
3) I can write well enough
4) The Wikipedia process is not convoluted and broken for casual contributors.
"The big epiphany for me was when I realized that the server has its own MVC, and the browser has its own MVC."
While I'd still advocate DRY over this POV (unless of course DRY leads you here naturally), I will agree this is a generally valid viewpoint, because you've got the server-client model built in there instead of glossed over. And you are now the first person who has gotten me to be generally agreeable about MVC used in the web world.
Which raises the interesting question of building a framework that builds this idea into the core, with server-side MVC, client-side MVC, and some sort of defined crossover instead of the usual hacky stuff that emerges from single-MVC.
I am doing a simialr thing. Except ASP.NET MVC 4 Web API on the server and Angular.js on the client. It feels very natural and simple to me. What I find odd is Angular.js works very similar to Silverlight, and my whole setup has similarities to Silverlight with RIA services. Yet SL+RIA never felt natural at all and was very difficult. I've not narrowed down where the difference lies.
Angular is very impressive. There are lots of small things that make it nice to use. Among them:
The lexical/nested scoping in the templates is just perfect. I've reviewed the documentation of all competing frameworks, and I couldn't figure how to do it in any of them. Since it was a primary requirement for my app, I went for Angular.
The service-based architecture, and the automatic service injection in controllers, based on parameter names are pretty nice too, as is the fact that you can pass arbitrary parameters to filters.
In a calendar widget that displays a month, I pad the `month` array with days of the surrounding months in order to get complete weeks. I wanted to have these days styled differently. `dayName` and `idem` are custom filters.
<ul id="calendar">
<li ng-repeat="day in month.days"
class="day {{day.day|dayName}} this-month-{{day.month|idem:month.month}}">
<div class="date-number">{{day.date}}</div>
Events go here.
</li>
</ul>
I found a blog post that gives a rundown on the evolution of MVC (https://billkrat.wordpress.com/2010/12/23/hello-world/) and links something similar to the document I had originally read (http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf). I think I had originally found something that was more of a prototype of this document, but the wording appears to be the same and more succinct. The blog post also links to an earlier version of the MVC model that included a fourth part, a "Thing".
One thing I found interesting in the blog article was the notion of "smart controls", but I can rationalize that away as another MVC module; after all, the Windows OS itself is handling all the interesting behavior, and the GUI app is borrowing the behavior. Depending on the toolkit that interfaces with the "smart controls", we get access to events (mousedown, keypress, etc) that can serve as input to one of our application's controllers.
Thank you for this comment. I was slowly losing my faith in HN developers knowledge.
Server MVC (Model2) is not the same as client MVC (the classic one). They are totally different architectures. Patterns that apply to one, don't apply to the other.
You can't get MVC with Rails/Django/Struts. You can get a nice MVC with a Single Page Application or with a desktop app.
This times 9000. I've noticed a trend amongst developers to jump at patterns and spend all their time trying to shoehorn their project into it because someone vaguely respected mentioned it on Twitter.
Patterns are great, but slavishly following them, and not understanding that there's often multiple patterns for different circumstances can lead to coding dragons.
I think this article goes even beyond the "is terrible and you're an idiot for using it", it actually "states" MVC is dead.
Honestly I'm sick of reading all those "x is dead"-alike articles. Hey, if you believe the web PHP is dead, Java is dead, C is dead.. etc... Technologies, patterns, languages or structures don't die, in fact, if you really fancy you could write your application using C code and compiling it into asm, why not? If it works, perfect! There are enough examples out there where old technologie works. And I think people tend to be spending too much time thinking why something is imperfect, or how to do it better, instead of actually making stuff that rocks.
If you really do have the need to improve something, prove it! Make a useable example, write a framework, library or new language if you really need to.
> And I think people tend to be spending too much time thinking why something is imperfect, or how to do it better, instead of actually making stuff that rocks.
I was with you until this. I think it's actually important to think about where flaws are and how improvements could be made.
The literary critic Howard Bloom actually argues that many of the best creative works are agonistic: they take a previous masterpiece and say, "I could do better," and from that claim do. The produced work ends up being a response, saying, "That was good, but here's your mistake, here's how it can be done better, and look how well it turns out."
MVC doesn't fit cleanly into the world of webapps, but it's still a lot better than business logic in view code, or monolithic classes than handle all HTTP interaction, etc. I've seen some really terrible Model 1 code in my lifetime.
I do however think there's still great benefits to MVC, if you're shovelling code into controllers and can't make it work like it should then MVC is not the right design pattern for the project. Like every other pattern it'll only work when it works, but MOVE sounds like an interesting addition that I might have a play with.