Advantages of Models

[eluser]nmweb[/eluser]
Slim controllers are usually preferred, you can move lots of stuff to models usually. Validation for example, the rules for your data (email, required etc.) can be defined in your model and are then available throughout your application. The model can then validate the data and tell the controller if something is wrong.

The data access layer is encapsulated by the model. So controllers interact with the model, models interact with the data access layer so you can change your datasource from xml to database without fiddling with the controller.

It all comes down to DRY (don't repeat yourself), say you want to mail the user every time he changes his password and there are three places in your application where he can do that. If you move the password mailer into the model you only have to write the code once and just attempt to save the database record on three places in your application, let the model determine whether the password is changed and mail the user if so. If you repeat yourself in your controllers chances are that stuff should be moved to the model.

[eluser]jalalski[/eluser]
I guess it's a different way of working. I prefer my Models to be simple creatures and not contain any application logic. Things like emailing and such don't belong 'down there' in the data layer.

But, if it works for you then it's a valid way of doing things.

[eluser]Colin Williams[/eluser]
I'm with jalaski on the model issue. Models shouldn't even know their on a web server (realize that the database class handles that). No emailing. No session handling. Nada. Just get data, store data, validate data (in a way). No getting post or get.

But I still wouldn't say, "If the controller is appearing a little bloated, it’s a sign that it’s time look at moving some stuff to a library, plugin or helper." Just because there's a lot of code doesn't mean it's all abstractible; there could be a lot going on. Even if it is, it doesn't mean it should be abstracted (it doesn't all come down to DRY; flexibility needs to be considered, among other things).

[eluser]nmweb[/eluser]
This pretty sums up what I mean: http://blog.astrumfutura.com/

[eluser]Andy Chapman[/eluser]
@nmweb: The problem I see with that article, or at least how it relates to CI, is that models in CI are not portable. That is, I couldn't take a CI model and use it outside of CI.

e.g.

Code:

class Test_model extends Model
{
    function Test_model()
    {
          parent::Model();
    }
  
    public function get_test_details($id)
    {
        $query = $this->db->get_where('test_details', array('id' => $id));

        if ($query->num_rows() > 0)
        {
           return $query->row();
        }        
        else
            return false;
    }
}

My model here extends a CI abstract class, and then uses CI's active record class for data access, therefore I can't use it anywhere other than in CI apps.

Am I misunderstanding something?

[eluser]nmweb[/eluser]
It's not really the point of moving your CI models elsewhere. However, it wouldn't be hard to do, they're not very much intertwined in your application. This has a lot to do with the CI architecture and is not terribly relevant. Models in Zend Framework are completely freeform.

Your model above is good, you abstract the data access by placing the model in between. If you would switch to an xml-source you'd only change the model, not the controller/views.

The gist of the matter is however that you declare the rules for your application in your model, all data passes by the model and so should obey the rules. As said in the article, controllers should not guard data. Is today the a user's birthday? Ask the model, not the controller. Form is posted, the controller notices the POST request and passes it on to the model, model gives the ok and the controller renders the 'success' page.

The best controllers are those so generic that they are almost obsolete. It requires a change in your thinking but I personally found out it pays off. The whole MVC pattern makes much more sense like this and it'll make your code better to maintain and understand. Although, I must say, CI is not the perfect candidate to implement this but that's a different discussion.

This article might also be helpful http://weblog.jamisbuck.org/2006/10/18/s...-fat-model

[eluser]Andy Chapman[/eluser]
Cool, that makes perfect sense. The term "model" encapsulates not just the data, but the rules and logic around the data (the "model" of the data if you will).

OK, now let's apply what you've just said to the common scenario of having a form submission and storing that data in a database.

The controller receives the request and the post data array.

The controller says to the model, hey, we have a request to save this data, here it is.

The model receives the data, validates it, and if it's happy with the data, stores it. Either way, the model communicates back to the controller, which in turn communicates back with the view.

The model should take care of any logic associated with the data, including validation and transformations.

The model should not however be reading directly from the $_POST array, as that means the model is tied to that specific method of receiving data. Instead, the controller should pass the received data to the model.

How does that sound? Am I On the right track?

[eluser]xwero[/eluser]
To add some more confusion i think there are three sorts of models
- core models
- validating models
- view models

Core models is the only model type that interacts with the data source without application knowledge. These models are called explicitly in other files and are most flexible by design.

Validating models are as the names says in charge of the validation and the decision making based on the validation. Others say models shouldn't access global variables but i think the validating and the view models are allowed to access it and the validating model even should have controller functionalities in case a flag has to be send to the controller to react on something data related.
To make it concrete you have a multi form so the validation model is the first to know if the form should be redirected or it should remain on the same part of the form. In this case if you call the the validation model method in the controller you have to check if there is an error message. And use that information as a flag. If you do this in the validation model you can use it as a controller, if the redirect needs to happen, and a view model, to pass the error string to the view.

The view model is closely tied to the view that is called by the controller. It is the staging place to prep the fetched data for the view.

The advantage of splitting the models into these groups are smaller files, more specific functionality in each file, smaller methods.

I have written a hook for this a while ago where i base the names of the models on the controller and the methods on the action. Since i began to use it i found it suitable in all kinds of situations.

[eluser]Colin Williams[/eluser]
I think the best way to have a model act as a validator is to only use it to define fields and rules for the Validation class. Not that it interacts with the Validation class, but it returns an array to the controller that will work with the Validation API. This is only recommended because of the CI framework's validation class, and I think it's the best way to integrate your model and CI's validation class without coupling them too tightly.

And xwero, I personally have never been such a fan of splitting up models like that, or anything similar. It makes sense to have separate config files, for instance, because each config can be seen as related to a specific set of functionality or a specific object. But if a model's representing one object, I don't see what is afforded by splitting it up again into general categories, like view, validate, etc.

[eluser]Andy Chapman[/eluser]
Hi Colin, yeah I was wondering about the interaction between the controller and the model when it comes to form validation.

To me, form validation should be the job of the controller as the presence of forms has nothing to do with the model of the data. The model should be responsible only for ensuring the data it needs and receives (passed to it from the controller) is valid. Of course, this means that essentially there could be a double up / redundancy in functionality. If the form validation is ensuring the presence of fields A,B,and C, and the model also ensures that there are values for A,B,and C before doing an insert/update, then the same thing is being done twice.

How do folks handle this?