Live data from Hacker News

MVC is dead, it's time to MOVE on

cirw.in

211–220 of 233 posts

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

#211
I like this. I'm not a UI expert in the least, but I've always felt that the "controllers" component was a bit ill-defined. It seems that the MVC division comes from a time when GUIs were for single-agent, deterministic desktop apps like calculators.

In a world where "social" apps are increasingly important (and this time I use "social" non-pejoratively, because even if 99% of "social" is crap, the other 1% is damn important) and notifications need a first-class status, MOVE (the separation between operations, which are agent-initiated, and events, which are observed and can come from anywhere) makes sense.

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

#212
post #96

Earlier quoted context omitted.

JSON and RSS views don't make sense - in MVC, views are visual representations of data (the model). Views are how the user percieves the application. JSON and RSS are just different methods for representing data to be communicated to other systems.

Not saying I disagree with you but then where exactly would the JSON and RSS output methods go in an MVC framework, if not in a view i.e. how would a different system or user consume/access their output? Directly from a controller? Would love to know your thoughts as I've always found MVC a difficult conceptual approach to grok when applying it to web apps (lots of code never seems to have an obvious M, V or C home).

I'm not 100% sure where it fits in, but I tend to write have a Formatter service that is used by the controller to pass the model to the correct view.

The Formatter inspects the Request to determine what format it should be (html, json, xml, etc.), and returns the correct View to the Controller, which then passes the Model to that View.

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

#213
post #72

If your controller has too much logic you should really consider putting more of it in your model and view. Maybe I don't understand MVC, and you all can tell me How Wrong I Am, but here's how I understand MVC at present: Your Model is a public API, a Service Gateway -- and it should do a couple of things in principle. The first is that it should be able to manage a list of subscribed view/controllers, and push updat…

Sounds about right to me. Model in MVC isn't data model, it is a model of the application domain, aka business logic. The controller is supposed to map low level input to high level model actions. The view goes the other way, high level model representation to low level operator display.

I think for a lot of people the Model is the DB layer. They then (rightfully) realize that you shouldn't combine business and DB logic, and then move their business logic into the Controller.

So they're fixing a valid issue with an invalid solution, causing bloated and dual purpose (business and application logic) Controllers.

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

#214
post #145

Earlier quoted context omitted.

Somewhat pedantic, but just throwing this out there: cars, bikes, and boats are all forms of transportation which can turn. They should probably inherit the concept of turning left, and then specify the exact meaning in their context. Obviously, I don't say "turn your handlebars such that the left side is closer to your chest," or "rotate your steering wheel counter-clockwise," when I mean to tell someone to turn lef…

I dunno about the last part. I think any logic inherently tied to the data should be in the model. The controller shouldn't have to worry about internals of the model any more than necessary. Here's an example. Suppose I create an i18n framework for handling numbers. I certainly am going to include in it a function for converting the number into the current user's localized format, and another one for converting the…

Converting the display format of data when requested by a view is exactly what a model is supposed to do.

However, instructing a contained object to take some action at the user's request that is unrelated to display or management of contained objects is neither the responsibility of the view or the model, but specifically the task of the controller.

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

#216

Earlier quoted context omitted.

jQuery UI and the charting lib are not external software, they are part of your system (application). By your logic, every possible digital representation of the model is a view because you can always dig up some tool somewhere to visualize your model. "Look, this floppy disk is a view in my MVC application, just insert it into the Commodore 64 and enter 'LOAD I_LOVE_MVC,8' "

That's not inconsistent. A view is just an interface layer. Whether it's interfacing to a human or not is irrelevant.

This whole discussion is about MVC. In order to argue about MVC we should have a common understanding of the principles of MVC. MVC was invented by Trygve Reenskaug. His definition of MVC is both consistent and readily accessible. Therefore I have repeatedly referred to him for a definition of the components of MVC. Surprisingly, many of the posters don't seem to regard the inventor of MVC as much of an authority on MVC, preferring instead to come up with their own definitions.

You have just provided a new definition of a view:

"A view is just an interface layer. Whether it's interfacing to a human or not is irrelevant"

If this definition suits your application, good for you. But you are no longer talking about MVC.

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

#217
post #62

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.

Thank you sir. I was worried nobody would mention DCI. I believe DCI is a far better solution to the MVC problem of dealing with 'algorithms' than MOVE. MOVE almost seems to be MVC plus goto.

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

#218

Earlier quoted context omitted.

> 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."

>"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."

Yes, that probably IS what would happen. I still wish I read more comments that said they had done this.

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

#219
post #133
post #113

Earlier quoted context omitted.

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

I'm currently building a single page app using this MVC-MVC approach. 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. That's it. http://angularjs.org/ http://nowjs.com…

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.

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

#220
post #59
post #43

Earlier quoted context omitted.

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

This sounds interesting. What Xerox document are you referring to and what is the most relevant part?
Post reply on HN