How complex should models be?

Question

When implementing models using the MVC pattern, how complex should my models be?

Let's say I have got a few tables like so:

User (id, password, created ...)
Emails(user_id, email ...)
Addresses (user_id, address ...)

I have got a controller called UserController. This controller should allow me to log users in, create users, etc.

<!-- language: php -->
class UserController{

    public function create($array){
        ...
    }

    public function login($email, $password){
        ...
    }
}

Should my models be very primitive, implemeting only CRUD operations via ORM? This would result in code like:

<!-- language: php -->
class UserController{

    public function create($array){
        $userModel->username = 'blah';
        $userModel->blah = 'blah';
        $id = $userModel->save();

        $emailModel->id = $id;
        $emailModel->email = "emailhere";
        $emailModel->save();

        //Do the same for addresses
    }

    public function login($email, $password){
        ...
    }
}

Or, alternatively, I could have models that are more complex:

<!-- language: php -->
UserModel{
    public function login($email, $password){
        //Do the joining and checking here, then return true or false to the controller
    }
}

Then in my controller:

<!-- language: php -->
userModel->login($mail, $password);

So, which is the better way? To stuff all the logic into models, or should I have models doing only the basic CRUD operations? Finally, how do I deal with table joins? Should they be dealt within the model, or in the controller?

Cheers

is not the user who has to have the login method, but the system or the auth model. A user object still not exist before login — Elzo Valugi, Jul 10 '11 at 09:46
Just a note: Why do you have an email model? Shouldnt it be sufficient to have an email field in the user model? — Alp, Jul 10 '11 at 09:56
Users can have multiple email addresses associated with their account in this application. — F21, Jul 10 '11 at 10:01
possible duplicate of [Understanding MVC: Whats the concept of "Fat" on models, "Skinny" on controllers?](http://stackoverflow.com/questions/3109715/understanding-mvc-whats-the-concept-of-fat-on-models-skinny-on-controllers) — Gordon, Jul 10 '11 at 10:07

JamesHalsall · Accepted Answer · 2011-07-10T10:26:20.113

Most people think of the "Fat Models, skinny controllers" paradigm, and it works better in the long run.

A great rule of thumb is to think about your Models as their own entity, in the sense that if you were to move your models to a different framework for example, they would still be functional.

A simple example would be saving information about an order on an e-commerce website. Let's say you want to save information about Tax, namely how much Tax is on the order. An abstract way of doing this is...

$tax_amount = $order_amount * (TAX_PERCENTAGE / 100);

Should we do this in the controller or the model? Suppose we did it in the controller, well... in our create action and our update action we would be calculating the tax, which makes for harder to maintain code and should the business rules of the e-commerce website change (say, we start selling to Tax exempt businesses or overseas business) then we would have to change any controller that saves order information.

If we were to calculate Tax in our Order model however, we would be doing it once in our save() method, which would be called when editing and adding orders.

public function save() {
    //calculate tax first
    $q = $this->db->query($sql);
}

Imo, it's better to enforce business rules in your model because it makes for more portable code and far less headaches when it comes to maintaining your code. Of course, there are people who will disagree, and this is a very subjective area.

EDIT:

Applying this to the specific question you asked, think about whether you would ever need the login() method anywhere else but your User model? It's possible you might want to split your models into different, more specific ones. But you could extend from your User model in that case.

What about if you were to take away your controller completely? Or if you wanted to interface with your models in an entirely different way (say via a different framework in the future). Thinking in this way you would be far better off with your login method in your User model.

Personally, I would be creating a login method on my model because it is an operation on data and that is what our models are for. I would also be creating a loginAction() method on my controller which would initiate the login() method on our model and perform any other action (for example, log failed attempts/redirect) that has to happen on post-login, should it be successful or unsuccessful. An example loginAction() may look as follows...

class UserController extends GenericController {
    public function loginAction() {
        $post = $this->form->getPost();
        if(UserModel::login($post)) {
            //do something
        } else {
            //do something else
        }
    }
}

Can you also give your advice about the initial question with user/login? — Alp, Jul 10 '11 at 09:58
I have also read about "Fat models and skinny controllers". So in my case, the actions in my controller should basically be a proxy to the operation in my model? For example, UserController->login() should just call UserModel->login()? — F21, Jul 10 '11 at 09:58
I've edited my answer to give my opinion on the specific problem — JamesHalsall, Jul 10 '11 at 10:26
Thank you! That's what I am heading towards at the moment. I guess in a similiar case, should each database table be wrapped into a model? For example to login, the user requires a valid email address and password. So should (in your example, the Usermodel) access an EmailModel? Or should the UserModel directly join the User and Emails tables using SQL? — F21, Jul 10 '11 at 10:59
For db specific stuff you should use special resource models. So, you will have< let's say User and UserResource classes. In this case you will be able easily to migrate to another framework/db engine. — Dmytro Zavalkin, Jul 10 '11 at 11:20

score 0 · Answer 2 · answered Jul 10 '11 at 10:06

0

All functionality which will or could be reused at different parts in the application should be accessbile globally, so that the coupling is low and there is no need to redeclare it.

I think you need an additional model for authorization and/or the current system parameters. The AuthModel could store information about the different authorization roles and the SysModel stores application parameters like the default login settings (e.g. use cookies yes or no).

The login method could be placed in the AuthModel then, which should be a good place in my opinion. Also the models are responsible to validate the inputted data, so the creation of new users should be in the UserModel.

answered Jul 10 '11 at 10:06

Alp

29,274
27
120
198

Let's say I've got an AuthModel with a login function. I need to join Emails and Users together to determine if there's a valid account. Should I then speak to the EmailModel and UserModel using ORM to determine if i could login? Or should I use direct SQL? Should I even have an EmailModel? – F21 Jul 10 '11 at 10:24
You said that every user can have an arbitrary amount of emails, which leads to the presence of an EmailModel. So, your `AuthModel:login()` method needs to communicate with both the UserModel and the EmailModel to determine if the login is ok. – Alp Jul 10 '11 at 11:23

How complex should models be?

2 Answers2