Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MVC is dead, it's time to MOVE on

cirw.in

Post reply on HN
Print view View original

51–60 of 233 posts

Re: MVC is dead, it's time to MOVE on

#51

Post by goblin89 »

benihana wrote: post #15

Seems like the Operation layer is a combination of controllers and business logic, which feels like a bad idea to me. If the models only wrap knowledge, but don't do any work, then it's the part of the Operation to both decide what to show and also get it in the correct format to show. This seems like it's doing too much and is analogous to the MVC problem of really fat controllers.

On a flip side you can get models that do too much. At one point I had a method on a model that, in order to get data into correct format, just went and rendered a [Django] template. It came to that naturally, the line is thin, and I now prefer to err on the side of models doing too little.

> it's the part of the Operation to both decide what to show and also get it in the correct format to show

Did you mean Views, not Operations, here? Or maybe I'm missing something.

Re: MVC is dead, it's time to MOVE on

#52

Post by Alexandervn »

Addy Osmani has a nice excercition [1] on the history of MVC in Developing Backbone.js Applications, where he states:

"Developers are sometimes surprised when they learn that the Observer pattern (nowadays commonly implemented as a Publish/Subscribe system) was included as a part of MVC's architecture decades ago. In Smalltalk-80's MVC, the View and Controller both observe the Model: anytime the Model changes, the Views react."

So, not really new actually.

[1]: http://addyosmani.github.com/backbone-fundamentals/#mvc

Re: MVC is dead, it's time to MOVE on

#53

Post by vincentmac »

peter_l_downs wrote: post #3

Are there any MOVE frameworks yet? I very much like the idea, but one of my favorite tests for "correctness" in a program is to use it to build something. Although it could be (and probably is) a reflection on my lack of knowledge, I find myself "fighting" with MVC frameworks like backbone whenever I try to use them. I would love to see if MOVE would be any better.

I think Express may be freeform enough to implement an app in this manner.

Re: MVC is dead, it's time to MOVE on

#54

Post by asolove »

tree_of_item wrote: post #25

Does anyone else not really get "MVC"? It seems like every person has their own idea of what it is and no two frameworks can agree on what the necessary parts are. I get the feeling MVC is mostly a bunch of handwaving about separation of concerns, motherhood, and apple pie.

The original MVC architecture was for GUI interfaces in Smalltalk. It was so helpful a design pattern it was borrowed for use in request/response web application, where naturally the use of each part was very different.

If you really want to "get" the original MVC, see the classic book "Smalltalk, Objects, and Design" [1] which explains MVC and other OO architectures as well as the principles behind them, which might guide you to picking an appropriate structure for applications that don't fit the GUI/MVC paradigm.

[1] http://www.amazon.com/Smalltalk-Objects-Design-Chamond-Liu/d...

Re: MVC is dead, it's time to MOVE on

#56

Post by guelo »

The best practices I've seen for MVC apps isn't to put all the logic in the controllers. What you do is to create a "services" or "managers" layer that is called on by the controllers. A userService, for example, might have a function

  user = userService.login(name, password)
It's also nice to abstract this service layer with some clean interfaces so that you can replace the underlying implementation, for example to move from MySQL to Memcached.

Using events for everything has appeal but my experience is that the added synchronicity problems creates unneeded complexity and makes reasoning through the logic and debugging hard.

Re: MVC is dead, it's time to MOVE on

#57

Post by rglover »

Wow. As a designer who recently took the plunge into learning MVC (via Ruby/Rails), this is incredibly easy to understand. It took a bit of thinking to understand MVC but for some reason, separating out the concept of operations/events makes it blatantly obvious.

Now an important question: how would you practically implement this? Would this dicate a separate framework/language altogether or something else (I have a cursory knowledge of development, so play nice)?

Edit Just noticed the footnote at the bottom of the article linking to these: https://github.com/bitlove/objectify and http://collectiveidea.com/blog/archives/2012/06/28/wheres-yo...

Re: MVC is dead, it's time to MOVE on

#58

Post by utilitron »

pestaa wrote: post #19
rorrr wrote: post #6

So you renamed "controllers" to "operations".

It splits controllers into operations and events. Out of the three terminologies (state, representation, flow), the third one is arguably the most tangled. I find it healthy to refactor it into reusable chunks (operations) and event-driven flow management. The problem was, in my opinion, that operations should have not been put into controller units. It attracted more copy-paste solutions in my experience.

What is the difference between that and adding a service layer to a MVC?

Re: MVC is dead, it's time to MOVE on

#59

Post by Xurinos »

jerf wrote: post #43
nicholassmith wrote: post #2

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 work…

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 doin…

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.

Post reply on HN