aka Model View Controller

A pattern or architecture for applications which involves separation of Model (business) logic from View (output) logic from Controller (form/input) logic. Which should make it easier to support multiple Views from a single set of business logic, among other things.

Mark Pilgrim has an excellent overview. Again, you should treat all of this more as an ideal than an actuality. No developers I know actually program like this, although the good ones at least try.

An alternative summary, which might not even be accurate

  • HTTP request is sent to Controller.

  • Controller does all the thinking - calls the Model to interact with Data Store (CRUD, etc.), makes decisions, generates result data objects.

  • Controller then calls the View with that data, so the View can render it. (Or perhaps redirects to a View? If so, does it do that via HttpPost to pass the data it already has (can you even redirect with a POST?), or else does it make the View do its own call to get its data?)

Ruby On Rails notes

  • URI path defines Controller, method/action - like '/store/add_item/'

    • creates 'Store Controller' class (subclass of 'Application Controller') with method 'add_item'

      • which is in file '/app/controllers/store_controller.rb'
    • creates directory 'app/views/store' to hold Views (it auto-generates basic CRUD views)

    • the Model is the schema file which is used by the ORM

Edited:    |       |    Search Twitter for discussion