MVC is dead, it's time to MOVE on

Yah, this reminds me of Ember.js "MVC". It's kind of like "MOVE" + a StateMachine.

http://emberjs.com/images/ember_mvc/embermvc.png

Operations are similar to controllers for sure. But where's routing or state? We don't have a full picture here.

After trying out that new meta-pattern, things get overly coupled, too many bi-directional relationships between state, views, models, and controllers/operations.

MVC is not dead. It has its warts, but there still is a strong developer community who build applications using MVC - through MVC based frameworks, and also by handrolling implementations that are an approximation of MVC. As long as there are enough people using it, MVC can't be pronounced 'dead'.

As to MOVE, the issue that the author points as the problem with Controllers in MVC is that'controllers are nice self-contained bits of.. what?'. At some point people will start asking these questions about 'Operations' and 'Events'. What would you classify as an 'event' vs an 'operation'. Some mature Rails projects that I've seen already uses this paradigm - there is an internal synchronous pub/sub event listener to which messages can be pushed by both the controller and the model. Even then, there is always a question of where to put what. Some answers are very clear - like an audit log which is only a side effect. But it is not the case always.

The author is trying to solve this 'classification' problem by giving us a more granular model. This can help to a certain degree - but there will be some point where even this wont help us. At that point we can choose go to a finer granularity, or ask the question whether all this extra organization is worth the hassle?

Abstractions are not without a cost. Some abstractions are too essential for any project. Some abstractions are nice to have. But all of them have a cost. In the case of MVC, the cost of the extra organization is paid many times over by the increased maintainability of the application. But given the number of components the MOVE paradigm advocates, I'm doubtful whether the added organization will be worth the cost.

I agree with what DHH said on a recent podcast - it is easy to talk about concepts in abstract and they can look really good. But what changes the game is a real implementation and being able to contrast the code 'before' the change and 'after' the change. This is not feasible all the time - some things have to go through the ideation and a slow testing phase. But at the least, I'm looking forward to see a non-trivial application that uses this paradigm. I'm ready to try imagining how it would have looked in MVC and decide whether the extra organization is worth it.

MVC is just a design pattern, a way to organize code, it's not a religion.

I don't know. This is essentially saying that the way to solve problems is to add additional layers of abstraction. If you want to see a bunch of examples of why that's a bad idea, take a look at any J2EE application.

RAPHT (https://github.com/DanielWaterworth/Raphters/blob/master/RAP...) attempts to something similar (adding more layers of abstraction to MVC) but I have the same problem with that.

If we were really understood the problem we'd have come up with a way to make things simpler, not more complicated.

I think the real problem is that MVC is understood by different people to mean different things but they think they're talking about the SAME thing. Back end developers tend to think of the view layer as a trivial thing ("It's just HTML and Javascript! How hard can that be?") and front end developers tend to think of the model layer as trivial. ("Look, my backbone.js code is handing out and consuming JSON, how hard can it be to persist that?")

When I read suggested code where each class has one "process" or "run" method, I think that someone who lives in an object-oriented world has reinvented functional programming.