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 Http Post 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 StoreController class (subclass of ApplicationController) 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

User Options Recent Changes Help Page