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

201–210 of 233 posts

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

#201

Post by blahbap »

corford wrote: post #131
blahbap wrote: 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).

Services that provide data as JSON and RSS are not part of MVC at all. Even if you use MVC for your application, not _every_ part of your application has to fit into MVC. You use MVC only for the part of your application that communicates with the user. Other parts of your application, like external APIs, should not be crammed into any of your MVC components. A service that provides RSS or JSON on request would simply fetch data in a database and send it along, bypassing all your models, views and controller entirely. (Note that the database is not considered a part of MVC).

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

#202

Post by einhverfr »

jaaron wrote: post #82

MVC, more than other design patterns, is horribly abused. Developers should keep in mind its GUI roots. Here's my "is it MVC?" litmus test: How much of my code survives if I drastically change the view? For example, if I want to switch to a new desktop, web or text console interface, can I reuse much of the application? Of course, architecture changes this significantly (particularly web architecture), but still, if…

I agree with this.

The way we chose to do things in LedgerSMB (starting with the new code in 1.3) is to adopt a sort of untraditional MVC. The view has to represent the model and vice versa (information present in the model thats not in the view is never used, information present in the view but not in the model is always discarded).

However, the controller scripts are agnostic of this structure. They just glue these together and process operations. Therefore depending on the changes to the view, you may or may not have to change the model, but you should not have to change the controller unless you want to change what a button does. Similarly for reports, you can change these to your heart's content and no underlying changes are needed at all.

We've run into a lot of resistance from folks more used to traditional MVC stuff because the controller only needs to know what it minimally needs to know (and usually this is virtually nothing). Since everything is hash refs passed around....

But in the end the approach works, and specifically because we try hard to keep things fairly abstracted and loosely coupled within the application.

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

#203

Post by einhverfr »

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…

One thing I have started to note is that MVC is a fractal pattern. For a non-trivial app, you can define almost every component as an MVC framework.

Not only is there an MVC on the web server and a MVC in the web browser, but there is an MVC in the db as well, if it is well designed and well encapsulated. For example a well normalized db may have a model (physical table structure), a view (logical table structure) and controller logic (which essentially maps these two together and may enforce other things like audit trails and app-level replication).

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

#204

Post by einhverfr »

rickmb wrote: post #122

"you end up stuffing too much code into your controllers, because you don't know where else to put it" And that wouldn't happen to have anything to do with the fact that "you" either don't know any other patterns or solutions besides MVC, or are under the impression that using MVC somehow forbids you to use other patterns? Not to mention the fact that the definition of MVC that the author uses is false (in a way that…

ummm... one nitpick.....

Everyone repeats history. Some repeat the good parts. Others repeat the bad parts. Learning from history allows us to try to stop repeating the bad parts and do better with the good parts.

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

#205

Post by nicholassmith »

andrzejkrzywda wrote: post #176
jerf wrote: 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…

Thank you for this comment. I was slowly losing my faith in HN developers knowledge. 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://new…

This times 9000. I've noticed a trend amongst developers to jump at patterns and spend all their time trying to shoehorn their project into it because someone vaguely respected mentioned it on Twitter.

Patterns are great, but slavishly following them, and not understanding that there's often multiple patterns for different circumstances can lead to coding dragons.

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

#206

Post by einhverfr »

drone wrote: post #145
alttab wrote: post #66

Earlier quoted context omitted.

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

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 number from the current user's localized format. I will probably also have functions to convert to/from db formats and to/from arbitrary formats. Not all of these will be called by the controller (in most cases, just the ones to/from the user's localized format and maybe an arbitrary format on rare occasions).

This way the controller script can just call something like $number->to_output; and get the localized string back. Other model objects can call $number->to_db and get a string suitable for entry into the db.

Interestingly in LedgerSMB 1.4 where we have done this, the number of cases where the model calls number i18n functions are remarkably small. These are usually called in the model or in the view simply because the controller probably shouldn't have to worry about this, and the view gets to worry about display logic.

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

#208

Post by Silhouette »

saraid216 wrote: post #75
Xurinos wrote: post #59

Earlier quoted context omitted.

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

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

The article about MVC on Wikipedia wasn't just slightly off. For a long time, it was completely overrun by people who seemed to think MVC is an architecture for web apps. Real MVC, as the term had been used for decades before the web apps abused it and still is in interactive GUIs today, was all but relegated to a footnote.

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

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

#209

Post by demallien »

cirwin wrote: post #117
scrame wrote: post #23

This sure looks like MVC, but they call the Controller "operations". The MVC abstraction has an issue with web applications, since the request-response cycle doesn't provide feedback as directly as the hardware-monitor-software cycle that the pattern was originally designed around. However, if the problem is that you are putting too much "logic" into your controllers, you should probably find a better place for it. I…

It's very similar you're correct, particularly when you add in the Manager/Service layer (something that I hadn't spent enough time investigating). The main advantage of Operations over controllers is that they're fully composable. You can take the operation that logs a user in (which displays the login screen, and awaits the user typing a username and password) and use it as a sub-part of any other operation. In a p…

The controller in MVC does have a bit of a dual nature, firstly it acts as glue code between models and views, allowing the two to be effectively de-coupled. The second task is a little more complex - views take user input eg mouse-clicks and key presses, and translates it into semantic events "OK button clicked", "Open File selected", which are then acted on by the controller.

Your post explicitly identifies these two roles and formally seperates them. This is perhaps not a bad thing, but I don't know that it justifies the title. Something like "The two faces of an MVC controller" might have been a better description...

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

#210

Post by regularfry »

blahbap wrote: post #199
sophacles wrote: post #153

Earlier quoted context omitted.

Ohhhh, I see now. So some data formats that render to screen through external software are views, like html, json, generated javscript or xml if they go through jQueryUI or charting libraries, but if it goes through other external software like RSS readers, or non html, json, or javscript formats, before making it to the screen, it is no longer a view. Thanks for the clarification!

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.
Post reply on HN