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

61–70 of 233 posts

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

#61

Post by ricw »

alttab wrote: post #13

This is certainly interesting. I like the event based model. Here are my thoughts: If your controllers are getting fat and spaghetti like, I wouldn't blame MVC. There are many patterns one can use that are compatible with MVC without going to a completely different architecture. For instance, if you need to encapsulate multi-model interaction you can create a presenter abstraction that the controller simply calls int…

Couldn't agree more. As long as you find a consistent way of splitting and placing your "Controller" code, MVC works perfectly fine. The problem is that a "Controller" is only vaguely defined and always application dependent. However, finding a good split and place for code is not easily accomplished and, in my experience, needs a couple of iterations to be perfected. The MOVE split seems useful for event based systems (webapps?), however it doesn't seem to encapsulate as wide a range of apps as the more vague MVC does..

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

#62

Post by Erwin »

An interesting new pattern here (from the creator of MVC) is DCI: http://en.wikipedia.org/wiki/Data,_Context,_and_Interaction

Essentially it's a way to move code where multiple objects collaborate to achieve something into its own separate class (Context). However when executing in a context, each involved object takes on a "Role" which grants its additional methods specific to this context.

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

#63

Post by martian »

This pattern is fantastic.

We use a similar pattern that we internally call "Actions". An Action, in our parlance, is similar to the Command pattern from the Gang of Four. It can be invoked from anywhere and performs a single state change on a single model, or even multiple models (if several need to be updated at the same time, in the same transaction).

Separating Actions from Models was a huge step in writing readable code, and it's immediately clear what is happening in the system at any given time. Any Action can invoke any number of "child" actions, as well, to maintain encapsulation. For example: when a user registers on the site, we trigger a RegisterUser action, which in turn calls a CreateUser action and a LoginUser action.

Basically, we took any complicated method on our models and turned them into Action classes. Common concepts like database transactions, logging, event tracking, and so forth, can now be abstracted away, and don't need to be re-implemented in each model class. It's a huge productivity increase and a real win for software engineering.

I highly recommend this general approach to any large software system, and I'm grateful that we're all experimenting with things beyond MVC.

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

#65

Post by EdwardTattsyrup »

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.

I think it's unfortunate that the author chose to use the word "model" in MOVE. It appears that the "model" in MOVE is not the same thing as it is in MVC. That risks confusing a lot of people.

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

#66

Post by alttab »

pestaa wrote: post #49
alttab wrote: post #13

This is certainly interesting. I like the event based model. Here are my thoughts: If your controllers are getting fat and spaghetti like, I wouldn't blame MVC. There are many patterns one can use that are compatible with MVC without going to a completely different architecture. For instance, if you need to encapsulate multi-model interaction you can create a presenter abstraction that the controller simply calls int…

Sorry, but data-bound events are not useless in server context. It might be exactly what we need when fat controllers go out of control. Perhaps you meant they are too much of a complication if taken too far to work across all concurrent requests? Binding data and behavior together breaks the rule of single responsibility, which I believe is far worse than designing separate roles in sepearate components that work to…

If "fat controllers go out of control" then you've already made multiple mistakes. I don't think re-inventing the wheel is the right approach to fixing a problem when the developer can understand their own mistakes instead of blaming a framework or architecture.

Are you suggesting that OOP breaks the rule of single responsibility? Any 'operation' that modifies the internal data should belong on the model. Would turnLeft() belong on a Car model? Or do you pass a Car into a turnLeft operation? In my mind a turnLeft operation shouldn't know the details of how to turn a car left, or a bike left, or a boat left. These operations belong in the Car, Bike, and Boat.

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

#67

Post by bradwestness »

guelo wrote: post #56

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

Yeah, I've always used MVC with a repository pattern for handling Model operations. The controller is still calling the operations here, and handling events triggered by the user.

The O and E in MOVE sounds effectively the same as the C in MVC.

Model objects are generally just POCOs (or POJOs, or whatever) and should not know about their storage mechanism or dealing with user events.

Sounds like he's basically been doing MVC wrong, and thinks MOVE is something new, when really it's just closer to the way MVC should be done in the first place.

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

#69

Post by rcgs »

utilitron wrote: post #58
pestaa wrote: post #19

Earlier quoted context omitted.

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?

There isn't, but then is MVC really MVC when you've added in another layer?

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

#70

Post by bradwestness »

trebor wrote: post #16
rorrr wrote: post #6

So you renamed "controllers" to "operations".

No. An operation appears to be a one-off "action" rather than a collection of actions (like a controller).

So basically he's just putting the controller methods in their own namespace. Which is all well and good, but I don't think anybody argues that all of your business logic has to be in the controller class for it to be considered MVC.
Post reply on HN