Controller or Model

[Braxton]

I am working with MVC and I am working on writing register method for my user class. The question I have though is: when validating the register form, should the if statements for checking length of username and password take place inside of the controller or is that something that the model should handle?

[hansford]

There is argument on both sides of this debate. Personally, I handle validation from within the controller. 

No need to clutter up your controller with validation statements though - create a validation class and let it handle all of that.

[gizmola]

It really depends on the capabilities of the Model system you are using.  If it was for example, something like Symfony2 and Doctrine2, the typical answer would be that the validation rules are attached to the model.  Of course with that said, form processing rules can get quite complicated, and since the form object lives and dies inside the controller, you will typically have the actual validation check occurring specifically in the controller logic.

 

 

Something like:

 

 

if ($form->validate()) {
    // Persist the data
    // Redirect as desired
} else {
  //redirect back to form, adding the error data
}

[ignace]

Should validation be handled by your controller? No, because depending on the number of systems there may be more then 1 controller accepting the same data. Is validation part of the model? Yes. Don't get caught up on details.

 

- View is what shows the response to a request of the user.

- Controller is what accepts requests and acts upon them.

- Model is everything else.

 

That said, you should keep in mind to keep your controller code to a minimum. Because too much code in the controller means that you'll be copy-pasting a lot between controllers. Encapsulate (that means put it in a class) if you write something more then 2 times.

 

You'll probably have come across services (if you are into SOA, (pun side note: in Belgium this is short for STD)). These services are a Facade to the model and mostly accept scalars (think productId).

 

class UserController {
  public function registerAction(Request $request) {
    $service = $this->get('service.registration');
    $form = $this->createForm('signup_form'); // another service
    $form->handleRequest($request);

    if ($form->isValid()) {
      $service->register($form->getData());
    }

    return $this->render('register.html'); // return Response object
  }
}

Suppose that at some time you switch to AngularJS and use a REST back-end your code won't look much different:

 

class RESTUserController {
  public function postUserAction(Request $request) {
    $service = $this->get('service.registration');
    $form = $this->createForm('signup_form');
    $form->handleRequest($request);

    if ($form->isValid()) {
      $service->register($form->getData());
    }

    return $this->redirect('users_list');
}

I say the $form is a service here, even though conceptually it's a client thing, it models how a client enters information into the system. It validates and turns the scalar input of the client into a model your system can work with. Edited November 13, 2015 by ignace

[hansford]

 

 

Is validation part of the model? Yes.

 

The rules went out the window long ago when MVC stopped matching up to real world of computer use.

"Business Rules" belong in the model. MVC is a pattern, not a rule. All of the frameworks around today break the rules. 

I know I'm not telling you anything you don't already know. I'm just arguing lol

[ignace]

I think most people simply misunderstood MVC because it's so dead simple. Only the View and Model part are significant, the Controller is nothing more but glue between them. In my career I never met anyone who understood MVC (and I simply assumed I understood by assuming that if their controllers had more code then their models, they were wrong).

 

Even in the academic sphere when I was taught Java and .NET, their controllers were littered with model logic and their models mere data placeholders. One of those teachers even went as far as simply making every class static and just call them anywhere, everywhere. At that point I knew that self-taught was the way to go.

 

And not all frameworks break the rules (I think none of them do). The one I show above is Symfony. Of course anyone can abuse a framework and put their model logic in their controllers. But I get why you think that, because a framework caters to all. And when you create something very simple there's no need to be all architect about it.