MVC is dead, it's time to MOVE on

Post by corford » Mon, Jul 02, 2012, 9:09 PM UTC

blahbap wrote: post #96

jshen wrote: post #83

Earlier quoted context omitted.

my rails apps pass this test with flying colors. Nearly all of my end points have at least 3 views. 1 for html, 1 for json (often used for ajax calls), and 1 for rss/atom.

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.

Post by pygy_ » Mon, Jul 02, 2012, 9:12 PM UTC

jerf wrote: post #113

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

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

    * manage authentication and authorizations,
    * ensure data integrity and
    * push data on update according to user permissions.

Post by jshen » Mon, Jul 02, 2012, 9:16 PM UTC

FuzzyDunlop wrote: post #109

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.

HTML is also one of those different methods. It just so happens that the browser renders it instead of spitting out the raw text. That said, non-HTML output bypasses the view entirely in Rails (it makes sense to), so it can equally be the case that the distinction is correct.

Post by jacobsteringa » Mon, Jul 02, 2012, 9:19 PM UTC

juliano_q wrote: post #93

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…

I agree, I really like the "services" layer. I used it for years programming with Java/Spring and missed a lot when learning RoR. I think it is no coincidence that the two RoR real-world projects that I worked had enormous controllers. The service layer is great to orchestrate operations between models and I don´t know a reason for not using it.

Post by Androsynth » Mon, Jul 02, 2012, 9:24 PM UTC

HeyImAlex wrote: post #130

blahbap wrote: post #124

Earlier quoted context omitted.

Let me give you an example. In your model, you have represented the salary of an employee as an integer. In a web application, the salary can be presented to the user through numerous different views - as a number on the screen (plain HTML), as a slider (jQuery UI slider), as a bar in a bar chart (using some charting library). The tools you use to build the view are not relevant.

> In a web application, the salary can be presented to the user through numerous different views - as a number on the screen (plain HTML), as a slider (jQuery UI slider), as a bar in a bar chart (using some charting library) as JSON encoded output, as XML....