MVC
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: | Tweet this! | Search Twitter for discussion
BackLinks: 2002-12-19-ServletBestPractices | 2004-08-30-DehoraMvcContraWeb | 2005-10-02-BangertPythonWebMvc | 2005-11-03-PyDispatcher | 2005-11-11-MvcPythonWebApp | 2006-07-01-DhhWorldOfCrud | 2006-10-02-YeggeJavaScriptMozilla | 2007-03-30-AviBryant | 2012-03-06-WattersUdellWebMakerLiteracyPerspectives | 2022-04-30-10ReasonsMvcFrameworksArentDinosaursButSharks | AspNetMvc | DjanGo | JavascriptClientFramework | ModelViewController | MsWindowsWebDevelopment | PyraMid | WagN
TwinPages: ThoughtStorms