Controller logic -- or model???

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Controller logic -- or model???

Post by alex.barylski »

I have a model, has your basic CRUD operations.

By default when someone views this page, the controller has no record ID to indicate which details to show -- it's the main landing page after login.

Because of this, I have some conditional logic in my controller to basically determine if the record ID is zero or invalid, in which case the entire models records are queried one by one, the average is calculated and that data is shown.

Otherwise, the valid ID is passed to the model and the details for that specific record are display.

So I ask: Should I refactor this logic into the model as a specialized method or does it make sense in the controller?

The model is used a few times throughout the site, but this additional conditional logic is not needed, whereas the CRUD ops are. This is really the only time these details will likely be calculated, so I currently justify keeping the logic in the controller.

What do you think? :)
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Controller logic -- or model???

Post by Christopher »

If "record ID is zero or invalid" determines whether or not to fetch more records, it belongs in the Model. If it determines how to display the record, it belongs in the View. If it determines which View to use, it belongs in the Controller.
(#10850)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Controller logic -- or model???

Post by alex.barylski »

If it determines which View to use, it belongs in the Controller
Because I implement a passive view -- does this rule equally apply to determining the model to use? I think that is the question I was trying to ask. Basically I think there is a need for 2 separate models. One for CRUD and another for statistics/reporting. Which one I use in the controller depends on whether the record ID is valid or zero (or invalid). Make sense?
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Controller logic -- or model???

Post by Christopher »

Hockey wrote:Because I implement a passive view
You are probably not implementing a "passive view". You are probably using a template library. The template library and the code that configures it is the actual View. The template is really more the data for the View.
Hockey wrote: -- does this rule equally apply to determining the model to use? I think that is the question I was trying to ask. Basically I think there is a need for 2 separate models. One for CRUD and another for statistics/reporting. Which one I use in the controller depends on whether the record ID is valid or zero (or invalid). Make sense?
Two different models? They hopefully have the same interface. Why not a Facade or Factory?
(#10850)
User avatar
Mordred
DevNet Resident
Posts: 1579
Joined: Sun Sep 03, 2006 5:19 am
Location: Sofia, Bulgaria

Re: Controller logic -- or model???

Post by Mordred »

1. "Valid id" is something which only the model should know about. Is 5 a valid id? Yes? Haha, gotcha, no! We don't have an object of this id, because it was deleted! Only the model can know this, so move it there.

2. On the other hand, the controller should know if it was valid, and if not, display something else (i.e. effectively use a different view). So you also need a way to ask for this from the controller. I personally do this by trying to init a model object with the given id, and then checking if it was "valid", whatever that would mean for a particular model.

3. And thirdly, if it wasn't valid, you want to pull some aggregate data from the same table. This calls for an "aggregate model", i.e. something which works not on singular objects from the model space, but on groups of them. A "Factory" fits in that definition, as it can create arrays of model objects, but I'm worried about your approach. Most aggregates can be calculated without the need of creating model objects - just by querying the underlying backend (think SQL's AVG() function). It's best to hide that under the hood of the "aggregate model" (my term, not sure what the books would call it). In my own approach (not advocating it in any way, it's just the best out there :) ) I "mix" the two models in one class - a set of member functions deals with the single-object model, and a set of static functions deal with en-masse functionality - searching, mass delete, whatever.
User avatar
John Cartwright
Site Admin
Posts: 11470
Joined: Tue Dec 23, 2003 2:10 am
Location: Toronto
Contact:

Re: Controller logic -- or model???

Post by John Cartwright »

Mordred wrote:3. And thirdly, if it wasn't valid, you want to pull some aggregate data from the same table. This calls for an "aggregate model", i.e. something which works not on singular objects from the model space, but on groups of them.
I prefer to keep the aggregate displaying from the individual records, typically because they have different roles and are not simply just displaying the data.

Code: Select all

 
class foobar extends Controller 
{
   public function index() {
      $object = $this->Model->load();
      //glorious controller code goes here to display ALL records
   }
 
   public function view() {
      $id = $this->Request->get('id');
      if (!$object = $this->Model->load($id)) {
         $this->redirect('/foobar/index'); //invalid id
         return;
      }   
      //glorious controller code goes here to display ONE records
   }
 
}
 
Thereby, all the controller is worried about is if the model has been satisfied. It doesn't need to know if the ID was valid, it just wants to know if the model is ok (which is determined by a valid id being passed.
Post Reply