Railsters:
I heard a rumor that the incorrect answer, "Controller", was in circulation out there.
The C should be as thin as possible, like a telephone patch-board. The View should be thick, but only with Viewey things.
The Model should be as fat as possible. Anything a user can do to the biz rules, thru the View, unit test can do to the Model directly.
So the question is: Where did this disinformation come from? Do any websites (or
Thin controllers. Fat models Dumb views
Although as I type this maybe Thick as a synonym for Dumb might be a better fit with the other two. <G>
And to drive the point home: http://www.railsenvy.com/2008/6/3/mvc-videos
Phlip wrote:
Railsters:
I heard a rumor that the incorrect answer, "Controller", was in circulation out there.
That's how I was taught MVC, long before I'd heard of Ruby: Models do some basic checking, but business logic belongs in the controller. That was the point of the controller; it gave a central place to put business logic.
The C should be as thin as possible, like a telephone patch-board. The View should be thick, but only with Viewey things.
That's the Rails take. Rails munges terminology a little. Rails models do a lot of what used to be done by controllers. I'm not saying it's a bad thing, but MVC far predates Ruby, and supposed "best practices" change over time.
The Model should be as fat as possible. Anything a user can do to the biz rules, thru the View, unit test can do to the Model directly.
That's not necessarily true.
So the question is: Where did this disinformation come from? Do any websites (or >cough< books) out there actually say the biz rules belong in the controller?
I first used MVC with MFC, about 10+ years ago, and in Java shortly thereafter. Fat controllers may have been advocated by MS back then.
Well that's not the original intention of Trygve Reenskaug when he conceived of MVC:
http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf
Trygve's original goal was separating UI logic from domain logic (what we commonly cause Business logic). The Model holds the domain information and methods for processing it.
The View is concerned only with presenting the view to the user, a model might have multiple views presenting different subsets and/or projections of the model.
The Controller deals with communicating with the user, it processes user input, and decides which views should be rendered and where.
So the Rails notion of MVC seems very similar to this 1979 version. Controllers process user input and decide which view to render, Views do the rendering, and Models do the heavy application lifting.
Subsequent variations of MVC, particularly those which piled application logic into the controller are perversions of the original idea.
Note also that Reenskaug talks about Editors which are objects which are associated with a view and are temporarily interposed between a controller and a view. I think if you squint just a little bit you can see the seeds of what Rails developers now refer to as a Presenter.
Rick DeNatale wrote:
Phlip wrote:
Railsters:
I heard a rumor that the incorrect answer, "Controller", was in circulation out there.
That's how I was taught MVC, long before I'd heard of Ruby: Models do some basic checking, but business logic belongs in the controller. That was the point of the controller; it gave a central place to put business logic.
Well that's not the original intention of Trygve Reenskaug when he conceived of MVC:
Thanks, I'll read that as soon as I have a chance.
Trygve's original goal was separating UI logic from domain logic (what we commonly cause Business logic). The Model holds the domain information and methods for processing it.
The View is concerned only with presenting the view to the user, a model might have multiple views presenting different subsets and/or projections of the model.
The Controller deals with communicating with the user, it processes user input, and decides which views should be rendered and where.
That's different from any form of MVC I've ever heard of, including Rails. Ordinarily, the views define the UI, and the Controller exists strictly behind the scenes, as implementation details.
So the Rails notion of MVC seems very similar to this 1979 version. Controllers process user input and decide which view to render, Views do the rendering, and Models do the heavy application lifting.
That's not how Rails works. You're mostly right about the Models, but the controllers are, as Phlip suggested, just "patch boards," not for user input. Sometimes a savvy user can send HTTP requests to a Rails application without going through any view, but that's not the intent.
One piece of "heavy lifting" still done by the controllers is access control; Models know how to answer questions, and don't intrinsically care who's asking. It's up to the Controllers to determine who gets to see what.
Subsequent variations of MVC, particularly those which piled application logic into the controller are perversions of the original idea.
"Perversions." You know, there are ways of making a point that don't involve blanket insults of everyone who disagrees with you.
Note also that Reenskaug talks about Editors which are objects which are associated with a view and are temporarily interposed between a controller and a view. I think if you squint just a little bit you can see the seeds of what Rails developers now refer to as a Presenter.
I'll have to look up Presenter.
I didn't read it as an insult...according to the dictionary:
'perversions: a perverted form of something' 'perverted: turned from what is right; misguided; distorted.'
Then every MVC implementation that differs from the original is indeed 'distorted' and therefore 'perverted'
Do we really need to try and interpret everything as flamebait?
I'm new to both rails and MVC, so please correct me if I misunderstand. But it seems that controllers DO handle user input for the typical web application. A view helps a user format that input, but it can't receive anything. In fact, I could just send an http request to a rails application before ever interacting with UI. The controller is what processes this request, consulting models if necessary. The view isn't involved until the application tries to send information back to me.
Brian wrote:
That's not how Rails works. You're mostly right about the Models, but the controllers are, as Phlip suggested, just "patch boards," not for user input. Sometimes a savvy user can send HTTP requests to a Rails application without going through any view, but that's not the intent.
I'm new to both rails and MVC, so please correct me if I misunderstand. But it seems that controllers DO handle user input for the typical web application. A view helps a user format that input, but it can't receive anything. In fact, I could just send an http request to a rails application before ever interacting with UI. The controller is what processes this request, consulting models if necessary. The view isn't involved until the application tries to send information back to me.
You could, but you ordinarily don't. A user typically deals with a web page, entering information in (e.g.) a styled form. The controller only deals with "input" in the sense of HTTP requests, and it doesn't know whether they come directly from some hacker, or from an XMLHttpRequest object in some Ajax application. In such a case, btw, the Controller sends back XML directly, without going through the view; so, if we're going to take the stance that Controllers deal with input directly, then we also have to see them as providing output directly. It makes more sense, IMO, to see the View as defining the UI, and the Controller as an implementation detail.
p_W wrote:
I didn't read it as an insult...according to the dictionary:
'perversions: a perverted form of something' 'perverted: turned from what is right; misguided; distorted.'
Then every MVC implementation that differs from the original is indeed 'distorted' and therefore 'perverted'
"Perversion" is an extremely derogatory term. That connotation may not be expressed by your dictionary, but I assure you, "perverse" is a very nasty way of referring to something, and implies strong disapproval. The most common use of the word is probably in relation to sex crimes. It's just not a nice thing to say. That doesn't mean Ron hasn't got the right to say it, especially if it accurately expresses his opinion; however, it's not something that ordinarily comes up in civil discourse.
Do we really need to try and interpret everything as flamebait?
Do we really need to turn every intellectual debate into a struggle for personal superiority? It's silly. If I told my coworkers their opinions were "perverse," I wouldn't have coworkers anymore.
That sounds more like Jacobson's Entity-Boundary-Control. Is there a chance you're thinking of that?
Michael
I'd suggest it's a serious mistake to assume your odd point of view -- which doesn't match up with either the m-w.com dictionary, or my own experience -- is shared by the majority.
Your assurances notwithstanding 
Michael Schuerig wrote:
Rick DeNatale wrote:
The Model holds the domain information and methods for processing it.
The View is concerned only with presenting the view to the user, a model might have multiple views presenting different subsets and/or projections of the model.
The Controller deals with communicating with the user, it processes user input, and decides which views should be rendered and where.
That's different from any form of MVC I've ever heard of, including Rails. Ordinarily, the views define the UI, and the Controller exists strictly behind the scenes, as implementation details.
By UI I mean both output and input. And the Controller and View are both involved.
So the Rails notion of MVC seems very similar to this 1979 version. Controllers process user input and decide which view to render, Views do the rendering, and Models do the heavy application lifting.
That's not how Rails works. You're mostly right about the Models, but the controllers are, as Phlip suggested, just "patch boards," not for user input. Sometimes a savvy user can send HTTP requests to a Rails application without going through any view, but that's not the intent.
No, I really understand how Rails, HTTP browsers work, and I maintain that controllers handle input and decide how to change what the user sees in response. This is partially in response to a later response you made to Brian.
if we step back and see how the user interacts with a web application through a browser, the first step is to make the initial request by getting the browser to send an http request to the app. This happens when he does something like typing a url into the address bar, or following a link.
The http request, typically a get here is the input I'm talking about. That input in the form of a request is routed to a controller, which typically interacts with one or more models, then renders something. That something is typically an html page from a rendered view, but could also be json, javascript, or a partial dom replacement for an ajax call, often view are involved in the rendering of this response.
The only thing that views have to do with input is to provide affordances by which the user may cause additional input requests to happen, whether they be links, buttons which generate ajax requests, etc. but the input is processed by the controller in the web application.
One piece of "heavy lifting" still done by the controllers is access control; Models know how to answer questions, and don't intrinsically care who's asking. It's up to the Controllers to determine who gets to see what.
Only in the simplest of access control. Usually there's model involvement here as well, although it's often not obvious because the controller interaction with the security model objects is done in before filters.
Subsequent variations of MVC, particularly those which piled application logic into the controller are perversions of the original idea.
"Perversions." You know, there are ways of making a point that don't involve blanket insults of everyone who disagrees with you.
As others have pointed out, you are over reacting to the word. The intention here was in the same sense as "a perversion of justice". No insult was intended.
Brian wrote:
I'm new to both rails and MVC, so please correct me if I misunderstand. But it seems that controllers DO handle user input for the typical web application. A view helps a user format that input, but it can't receive anything. In fact, I could just send an http request to a rails application before ever interacting with UI. The controller is what processes this request, consulting models if necessary. The view isn't involved until the application tries to send information back to me.
Regardless of the direction data travels, a controller should dispatch to the view or model as soon as possible. For example...
Model.create! params[:model]
That common idiom passes <form> parameters directly into the createe, in the model. This might look like a violation of the rule "no view data leaking into the model", where the params are indeed CGI Query details wrapped up in a convenient package, but note that params[:model] should only contain data primitives - strings and strung integers.
In real life coding, actions can get thick. They might need to use lots of if statements to triage input, for example. The rule "all biz logic in the model" is not a rule, it is a goal. The closer you get to it, and the more often you refactor a design towards that goal, the better.
Subsequent variations of MVC, particularly those which piled application logic into the controller are perversions of the original idea.
"Perversions." You know, there are ways of making a point that don't involve blanket insults of everyone who disagrees with you.
Mr. Manners reminds the Gentle Poster(s) that the early 1980s were, indeed, quite perverse...
Jeff Schwab wrote:
That's how I was taught MVC, long before I'd heard of Ruby: Models do some basic checking, but business logic belongs in the controller. That was the point of the controller; it gave a central place to put business logic.
Could you cite? It's flat-out wrong, and a friend of mine seems to have flubbed an interview by stating the correct answer.
The Model should store things your boss says, like "client X can handle Visas and Mastercards, but client Y can handle only Visas". Business rules.
Because controllers are busy controlling, you can't refactor the crap out of them, to leverage tricks like inheritance. X could inherit Y, and add Mastercard handling. (Please note that's a contrived example that would not withstand even cursory domain-driven analysis!
Models have only one predefined role - persistence into a database - so they are free to otherwise refactor their logic around until it's DRY. If you wrote a non-trivial Rails app without this refactoring and designing, your controllers are going to rapidly devolve into unmanageable brambles of tangled thorny logic...
In a system where the controllers are not so constrained (CGI, Ajax, HTTP, etc.) they are free to refactor into more subtle designs. Some projects, using other platforms, could conceivably store lots of business rules in objects that also control. That still does not mean it's a good idea.
The Model should be as fat as possible. Anything a user can do to the biz rules, thru the View, unit test can do to the Model directly.
That's not necessarily true.
That is extremely necessarily true. Defining designs in terms of how to test-drive their creation is a simple but powerful way to explain generic design guidelines. Think, for example, of the tests required to generate one of the designs in the book /Design Patterns/.
When you are writing an application, you should respond to the business rules in your requirements by TDDing them into your models first, then wiring them up to your Views. There's simply no counter-example for this practice.
So the question is: Where did this disinformation come from? Do any websites (or >cough< books) out there actually say the biz rules belong in the controller?
I first used MVC with MFC, about 10+ years ago, and in Java shortly thereafter. Fat controllers may have been advocated by MS back then.
MFC exploits "vendor lock-in" by tempting you with a wizard. I suspect Rails is an example of a competing platform that simply doesn't need one! Beyond script/generate...
Phlip wrote:
Regardless of the direction data travels
travel.
<voice size='tiny'> sorry </voice>
Phlip wrote:
Jeff Schwab wrote:
That's how I was taught MVC, long before I'd heard of Ruby: Models do some basic checking, but business logic belongs in the controller. That was the point of the controller; it gave a central place to put business logic.
Could you cite?
No; as I say, this was 10+ years ago. Again, I'm not arguing what it "should be," nor what it "originally was;" however, I am telling you that a lot professional engineers, including me, were originally taught that business logic belonged in controllers. When I first learned of MVC, I was undergraduate student, not an expert on OOD. I don't code my Rails apps with thick Controllers, but I am bothered by this cult-like adherence to some One True Way of Agile programming. We're going to end up with a lot of bad software and lousy developers.
The Model should be as fat as possible. Anything a user can do to the biz rules, thru the View, unit test can do to the Model directly.
That's not necessarily true.
That is extremely necessarily true.
"This is widely considered a good idea" != "This is necessarily true"
Defining designs in terms of how to test-drive their creation is a simple but powerful way to explain generic design guidelines. Think, for example, of the tests required to generate one of the designs in the book /Design Patterns/.
Whether TDD is a good idea has nothing to do with how functionality should be apportioned among Model, View, and Controller. In particular, Controllers need tests of their own, no matter how much functionality you stick in the Models. (Unless you're going for only a Model/View paradigm, as some would argue Java Swing uses.)
When you are writing an application, you should respond to the business rules in your requirements by TDDing them into your models first, then wiring them up to your Views. There's simply no counter-example for this practice.
I believe you've been misled, and that you are mistaken. I'm not sure how else to say that, nor do I have any interest in arguing with a zealot who makes such absolutisms.
So the question is: Where did this disinformation come from? Do any websites (or >cough< books) out there actually say the biz rules belong in the controller?
I first used MVC with MFC, about 10+ years ago, and in Java shortly thereafter. Fat controllers may have been advocated by MS back then.
MFC exploits "vendor lock-in" by tempting you with a wizard. I suspect Rails is an example of a competing platform that simply doesn't need one! Beyond script/generate...
Rails is more "wizard" driven than MFC ever was, with scripts to generate just about everything. MFC was that way because it was meant to encourage consistent look and feel among applications; Rails is that way because it relies heavily on conventions to work properly. If you really want to pick an "our way or the highway" development framework, take a look at Cocoa.
Robert Walker wrote:
Jeff Schwab wrote:
take a look at Cocoa.
Which, by the way, is probably the most brilliantly conceived event-driven MVC framework I've ever had the pleasure of using. The very fact that you play by it's rules by doing things "it's way" is much of what makes it so.
Correction: "its rules" and "its way." Sorry for the misuse of the apostrophe.
Robert Walker wrote:
Jeff Schwab wrote:
take a look at Cocoa.
Which, by the way, is probably the most brilliantly conceived event-driven MVC framework I've ever had the pleasure of using. The very fact that you play by it's rules by doing things "it's way" is much of what makes it so.
Mostly agreed. It's very much like Rails, or C++ template metaprogramming, in the sense that convention is leveraged to define program structure. Restrictions aren't necessarily a bad thing. The one aspect of Cocoa development that does really bother me is that it's only really meant to be done in XCode, with which I am not thrilled.
Keep up to date with Rails on Twitter and This Week in Rails
Policies: Conduct, License, Maintenance, Security, Trademarks