81–90 of 233 posts
>the problem with MVC as given is that you end up stuffing too much code into your controllers, because you don't know where else to put it.
What was that? You stuff all of your logic into controllers then claim that MVC is broken? Your ugly face is broken. Uglyface.
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 cannot swap out the view, then I'm losing out on one of the significant advantages of an MVC architecture. One way to make sure this works is to start with 2 views from the beginning - the view you're actually going to ship, and a headless view for tests.
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…
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."
So you renamed "controllers" to "operations".
And am I incorrect in seeing it as simply MVC with an events bus? Welcome to everything backbone.js already brought to the table.
app.trigger 'boom'
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."
"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."
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 issue I have with traditional web-framework MVC is that it assumes that each URL associates with one controller, which I've found to be very straightjacket-esque. Often the pages I'm building have many separate bits of functionality present, from simple stuff like a login box, numerous widgets, and then the main thing the page is about.
In lift, each URL maps onto a view, which will contain the templating code for that page, including perhaps inheritance to pull in an overall template, and then will contain one or more (and perhaps MANY) snippet invocations.
A snippet in Lift is kind of sort of like a controller method. It takes the contents of it's template tag as input, and as output returns a transformed document tree, using what ever resources (models, web service calls, calling out to other classes, etc) it wants to do that.
If you write the snippets in a general way, binding text off of IDs, this allows you to get different outputs for the same data, depending on how you call the snippet - it's like passing a partial template in as a closure. Very different but powerful - the snippet handles the LOGIC, but only abstractly the templating.
It's a very powerful paradigm - it frees you from the MVC straightjacket, since you can arrange and organize your code however you like, but forces very strict separation of concerns - it forces you to compartmentalize your business logic, but doesn't force you to do it a certain way. Lift does really cool stuff with your xHTML/HTML5 templates too - it's truly operating on a server-side DOM tree, none of this is textual substitution.
http://www.assembla.com/spaces/liftweb/wiki/Templates_and_Bi... for more info.
What do you think helpers are in PHP MVC frameworks? They are code blocks that should not go in controllers but are required; like a password generator or reformatting for print command.
Go use Symfony to see how events and MVC mash up together. They do a good job in there.
Author's next post will be about including services for controllers/helpers/actions that are called more frequently. Once again, Mr. Author, check the PHP framework called Symfony.
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…
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.