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.
(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.
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.
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."
"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."
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.)
(In my experience most Wikipedia edits are gratefully received, assuming you provide references for your claims. Kind of like HN, really)
"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.
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.
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 use Angularjs in the browser, now.js for the interface, and, at the moment, custom code on the server that follows the MVC pattern.
The server is lightweight: its role is to
* manage authentication and authorizations,
* ensure data integrity and
* push data on update according to user permissions.
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>
.this-month-false{opacity: 0.7;}
.sunday{clear:both}
.day{float:left;width=...;height=...;}
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.
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.
A similar discussion was already here: http://news.ycombinator.com/item?id=3035549
Patterns are great, but slavishly following them, and not understanding that there's often multiple patterns for different circumstances can lead to coding dragons.
Can you expand more on this? I've used MVC for webapps quite a bit, and find it to work well.
You haven't used MVC, you have probably used Model2. The post we're discussing is about MVC.
http://andrzejonsoftware.blogspot.com/2011/09/rails-is-not-m...
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.
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."