Set SQL clauses from controller or from model?

[eluser]Mark Skilbeck[/eluser]
I just recently realised the basic PM system for a site I'm developing has a couple of flaws - easily fixed flaws, of course, but I still feel shameful for my crap planning, nonetheless.

The problem is, we have a sender and a receiver of PMs. To differentiate between the two, we need to use different WHERE clauses in the SQL. So, do we do these from the controller, i.e

Code:

public function outbox ( )
{
    $this->db->where( ... );
    // now pull data from model
}

Or pass the data to my model and let the model do the work?

Code:

public function outbox ( )
{
    $data = array ( 'pm_to' => $this->username );
    $this->MailModel->getMailData( $data );
}

I can see advantages and disadvantages for both: Setting the clauses in the controller allows for easily maintained and readable code, yet it's not completely seperating my business logic from the controller; passing the data to the model and letting it do the work maintains the MVC structure, but I may have to add some complexity to the method to allow for the different types off clauses.

I'd love some thought on this.

Btw, my OOP theory is terrible, and I just can't seem to grasp it. So you can bet your bottom dollar I'll be bugging you guys with questions from now on. 8-/

[eluser]jedd[/eluser]
Model, definitely.

Why not pass parameters to the model call?

Controller:

Code:

public function outbox ( )
{
    $messages_from = $this->Mdl_pm->get_messages_from ($user_id);
}

And in your model - Mdl_pm - have a method thus:

Code:

get_messages_from( $user_id = NULL )  {

     $query = $this->db->query ("SELECT *
                            FROM  private_messages
                            WHERE from=". $user_id );
    // Tidy up if you want, then return the $query->result_array()
    }

in your model, that returns an array of messages.

You could get funky and have dual-use get_messages () model function that takes two parameters, the user_id and a string that's either 'from' or 'to' (or similar)) but I prefer the separate functions approach.