in MVC, where do you draw the line between a controller and model?

Question 1

I've seen code written where almost all non-route related code is passed to a model. I have also seen code where all database persistence is handled by a model, but non-DB processing is handled by the controller.

Which is the better approach?

Question 2

The line between controller and model is actually quite clear.

Model is your application's heart. It contains the business/domain logic required to solve the problem your application was written for. The Model is usually layered into several other layers, e.g. persistence, services, domain, etc. It's a common misconception that the Model is just the database, as much as it is a common misconception that the database should be an ActiveRecord.

The controller (and the view) are part of the presentation layer. A controller's sole responsibility is to receive and handle user input directed towards your application and delegate this to the appropriate parts in the model. Nothing more. It should not handle complex application flow or code of your problem domain. You want controllers to be skinny and models fat with logic. The Model should not know about either C or V and you should be able to swap out V and C for a different presentation layer without having to touch your M.

See MVC Excerpt in Patterns of Enterprise Application Architecture

Question 3

If you're validating the data on client side (i.e Javascript validation) which is absolutely not enough and not secure at all, You should implement it in View.

If you're validating data on server side, And your validation does not require application business logic (i.e you're not checking to see if the user has enough credit in his account), You should validate in the controller.

If the validation requires business logic, Implement it inside the model and call it via controller.

Postback validation is not good since it puts lots of pressure and delay, And the only advantage is to the programmer (not to be accounted).

You can use regex for most of validation, Which has the same syntax (almost) on PHP and JS.

Question 4

The controller picks up the view variable in the url and using these determines which view needs to be used. It then sets the view to be used. The view then calls the model to fetch the data it requires and then passes this to the tmpl to be displayed.

Below is a simple setup of how this all works together:

components/com_test/controller.php

class TestController extends JController
{

  // default view
  function display() {
    // gets the variable some_var if it was posted or passed view GET.
    $var = JRequest::getVar( 'some_var' );
    // sets the view to someview.html.php
    $view = & $this->getView( 'someview', 'html' );
    // sets the template to someview.php
    $viewLayout  = JRequest::getVar( 'tmpl', 'someviewtmpl' );
    // assigns the right model (someview.php) to the view
    if ($model = & $this->getModel( 'someview' )) $view->setModel( $model, true );
    // tell the view which tmpl to use 
    $view->setLayout( $viewLayout );
    // go off to the view and call the displaySomeView() method, also pass in $var variable
    $view->displaySomeView( $var );
  }

}

components/com_test/views/someview/view.html.php

class EatViewSomeView extends JView
{

  function displaySomeView($var)  {
    // fetch the model assigned to this view by the controller
    $model = $this->getModel();
    // use the model to get the data we want to use on the frontend tmpl
    $data = $model->getSomeInfo($var);
    // assign model results to view tmpl
    $this->assignRef( 'data', $data );
    // call the parent class constructor in order to display the tmpl
    parent::display();
  }

}

components/com_test/models/someview.php

class EatModelSomeView extends JModel 
{

  // fetch the info from the database
  function getSomeInfo($var) {
    // get the database object
    $db = $this->getDBO();
    // run this query
    $db->setQuery("
      SELECT 
        *
      FROM #__some_table
      WHERE column=$var
    ");
    // return the results as an array of objects which represent each row in the results set from mysql select
    return $db->loadObjectList(); 
  }

}

components/com_test/views/someview/tmpl/someviewtmpl.php

// loop through the results passed to us in the tmpl
foreach($this->data as $data) {
  // each step here is a row and we can access the data in this row for each column by 
  // using $data->[col_name] where [col_name] is the name of the column you have in your db
  echo $data->column_name;
}

Question 5

It is tempting to put everything in the AppDelegate, but if you start doing this, then your AppDelegate will be full of reference hacks. If you are doing a strict MVC, then you should have 3 things:

A Model
A View Controller (Only for view logic)
A Controller (For coordinating between the view and the model)

So for example, I have a model Foo and a Foo controller. I would have:

Foo.m (Model)
FooViewController.m (Displays a Foo)
FooController.m (Controls the logic)

And finally, to answer your question, I would store my references to Foo's in the foo Controller. I like to use singletons for my controllers, but thats just me. If you do use a singleton, you can just do something like this: [[FooController sharedInstance] listOfFoos] to get your Foo's

Question 6

It's really fairly simple: architecture is about the design decision you make to meet the "non-functional" requirements: requirements like cost, maintainability, performance, reliability, availability, and security. This about a web application: you can build it in a zillion ways, from a big C program that runs as a CGI (really, we used to do that), a Python webapp, to a J2EE application, to a LAMP application. Any of them would have the same functional behavior, they all would post the same pages; the differences come in when you try to change the C program's database or load-balance your big LAMP application.

in MVC, where do you draw the line between a controller and model?

Answers

php,model-view-controller