

Rails MVC VS Sproutcore MVC - gmoeck
http://gmoeck.github.com/2011/03/10/sproutcore-mvc-vs-rails-mvc.html

======
sunjain
Although Sproutcore and Rails seems to be geared towards different domains(and
seem complimentary to each other); the comparison was quite useful because of
the simple way it was explained.

------
l_frequency
The easier way to explain it is that Rails is not true MVC (true being defined
by the original intention as described by Trygve Reenskaug for Smalltalk).
True MVC is an architectural pattern based on the composite and observer
patterns and is designed for synchronous apps. This is why Cocoa or Sproutcore
are more like true MVC.

Rails is Model2, which is the web adapted version of MVC that is popular in
server-side web dev.

~~~
tzs
Sproutcore doesn't sound much like Smalltalk MVC. In "Applications Programming
in Smalltalk-80(TM): How to use Model-View-Controller (MVC)" by Steve Burbeck,
which describes how Smalltalk did it, it says:

    
    
       In the MVC paradigm the user input, the modeling of the
       external world, and the visual feedback to the user are
       explicitly separated and handled by three types of object,
       each specialized for its task. The view manages the graphical
       and/or textual output to the portion of the bitmapped display
       that is allocated to its application. The controller interprets
       the mouse and keyboard inputs from the user, commanding the model
       and/or the view to change as appropriate. Finally, the model
       manages the behavior and data of the application domain, responds
       to requests for information about its state (usually from the view),
       and responds to instructions to change state (usually from the controller).
    

<http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html>

Looking at the Sproutcore diagram given in the article, it looks like that in
Sproutcore input goes to the view, which then decides to pass it to the
controller. In Smalltalk it sounds like input goes straight to controllers--
views have no idea input happened unless a controller tells them about it.

It's not quite clear to me from the article, but it also looks like maybe the
view gets what the information about what to display from the controller
(which gets it from the model). In Smalltalk it sounds like the controller
would tell the view that the view needs to update, and the view would talk
directly to the model to get the data it needs.

~~~
jerf
In my opinion, there is _no such thing_ as an MVC web application, if you are
really serious about the term _meaning something_ and not just being a pretty
paint color to put on your framework. MVC has nowhere for a client/server to
go, and that's the sort of detail that shouldn't be glossed over.

"Something like" MVC is certainly possible, but MVC directly is pretty much
confined to something without a client/server in it, or a cloud, and also is
pretty tightly coupled to Object Orientation, too.

I think it's better just to go with "separation of concerns" and "don't repeat
yourself", and pretty much whatever comes out of the end of a design based on
those things will be better than trying to jam MVC in _a priori_. Maybe it'll
even be MVC, if that's what fits, but MVC isn't _specially_ good, it's just
one point of a myriad of points on the good-DRY/SoC frontier.

------
baddox
There's additional confusion in Django, since what Rails calls "controllers"
are called "view" functions in Django.

~~~
elithrar
Django likes to call it 'MTV', or Model-Template-View. Templates are similar
to Rails' Views (markup with variables/tags) & Views are similar to Rails'
Controllers (methods used to validate/process data coming from/going to the
Model).

~~~
baddox
Yeah, this thread shows that even frameworks that have things called models,
views, and controllers use them in different ways, so it's really not a big
deal. It is, however, difficult to word things when explaining to a Django
developer the differences between it and Rails.

