Should you create models that don't touch your DB?

[eluser]coldscooter[/eluser]
As a rule, should you create models that have no contact with your database?

[eluser]skunkbad[/eluser]
I have. Used them for validation callbacks, as well as menu data.

[eluser]xerobytez[/eluser]
Sure, the purpose of a model is to obtain and serve data to your controllers. This data can be stored in a database, file or even a remote API on a different site. Doesn't necessarily have to be associated with a database!

[eluser]boltsabre[/eluser]
Not sure what you're doing, but if you are just "removing" some code from a controller to a model (perhaps for the sake of keeping your controller code smaller?), you can technically (and functionally) put it in a model, there is nothing stopping you, it will work. But if this is the case, this code is better moved to either a helper, or externalised into a library, especially if it is code blocks that you are using in more than one controller.

If it's code that that you are only ever going to use in that one controller, you can just isolate it into private function(s)/method(s) at the bottom of your controller class, thus keeping your normal public functions smaller in code size.

It all really depends on what you are doing, and what you want to achieve.

[eluser]scibuff[/eluser]
If you adhere to the Fat Model Skinny Controller content (and you should), your controller shouldn't be doing anything apart from handling http requests. That is, a function in the controller should look like this

Code:

public function foo()
{
    // process get/post parameters, e.g. validation
    $this->load->model('foo_model');
    $foo_view_data = $this->foo_model->get_data();
    $this->load->view( 'foo_view', $foo_view_data );

}

So yeah, there will be models that can (and most likely will) not have anything to do with the database.

To be honest, I find this idea spread around (not only php) frameworks that a model corresponds to a db table completely appalling. A truly elegant (and OOP) way would go along the lines of data adapters, e.g. db/file/cache/3rd_party_api adapter, and the model only acts as an intermediary between the controller and the appropriate data source. Think of it this way: Your mom (end user) sends you (controller) to buy groceries (model). You can use any grocery store (adapter) you like as long as you bring back what she wanted, it doesn't matter that you got it at Tesco or some local shop.