Rick DeNatale wrote:
> On Thu, May 28, 2009 at 10:17 AM, Jeff Schwab <[email protected]> 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:
> 
>  http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf

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.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Talk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to