Database Queries & Model interfaces

Say a model exists with the following interface:


class CarsModel{

  // List all cars
  function index(){
  }
 
  // View car where $id == car.id
  function view($id){
  }

}

Assume a Cars table and a Manufacturers table exist in the database.
Also, say there is a lookup table that maps cars to manufacturers.
There also exists a link or button on the webpage that lets a user list all cars by a certain manufacturer.

The MySQL syntax is straight forward, however the Controller and the Model do not know MySQL syntax.

So how should this be implemented?

Should the following method be added to the CarsModel :

function getCarsByMfr($mfr);

This method will then use an object that knows MySQL syntax (maybe a data mapper class) to make the query.
There may be many other buttons on the webpage that let you SORT, list cars by color, etc etc.

How should all these permutations be handled? Should the various functions be added to the Model or should numerous optional parameters be added to the index() method?

What is the right approach to this problem when trying to stay true to the MVC pattern and Object Oriented design? The solutions listed above would work, unfortunately they do not seem elegant, efficient or ideal.

Your model should have no knowledge of how it’s going to be used, things such as “Index” and “View” are not model operations. They are actually their own MVC triad.

Your model should contain things like “findByManufacturer()” and “findAll()” which are called by the view.

Ok. So if the View calls these methods, what does the controller do in this instance?

I would have thought the flow would be like so:

  • User clicks List By Mfr link = www.mysite/cars/byMfr
  • Controller receives request and does the following:
  • $_data = $_carmodel->findByManufacturer(); $_view->setData($_data); // <-- spoon feed view data. frowned upon by the author in one of the articles you posted earlier $_view->render();


  • Another option is not to pass the data to the View, but have the view call model->getData() as one of the first instructions in the render() method.

That was likely my article :slight_smile:

In MVC proper the program flow would work something like this:

controller calls:


$this->model->filterByManufacturer($manufacturerId);

Then the view calls:


$records = $this->model->findFiltered();

Now, it may be overkill to use models in this way. (See http://www.jdl.co.uk/briefings/mvc.html for the difference between an application model and a domain model. What you have is the domain model)

One way of simplying it is to combine the application model and the view so the controller does:


$this->view->setManufacturer($manufacturerId);

and the view does:


$records = $this->model->findByManufacturer($this->manufacturer);

Which way is best is open to debate. However, doing the latter removes any possibility of sharing the same instance of a model between multiple views.

Essentially the problem is one of separating the state of the domain e.g. which manufacturer owns which car? and the state of the application e.g. what is the current filter on the data within the application?