MVC Action/Command as controller method or distinct class/object

Lord_Yggdrasill

Well in most available PHP frameworks we see the actions/commands being organized as methods inside app controller classes, take Symfony's controller class as example:

// src/Acme/HelloBundle/Controller/HelloController.php
namespace Acme\HelloBundle\Controller;

use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;

class HelloController
{
    public function indexAction($name)
    {
        return new Response('<html><body>Hello '.$name.'!</body></html>');
    }

public function updateAction(Request $request)
{
    $form = $this->createForm(...);
    $form->bindRequest($request);
    // ...
}

}

In Martin Fowler and Matt Zandstra's book however, the actions/commands are organized as separate classes from the controller. The controller will instantiate the appropriate command objects and then act upon them. This is demonstrated by the example on sitepoint.com, the code is a bit old with PHP4 but it is the architecture that we care about. Also note due to the simple nature of the script, a front controller itself is more than enough to handle the command requests, otherwise several different App controllers will be taking care of groups of commands/view objects:

/**
* The FrontController's job is to look at the incoming HTTP request
* to see what task the user of the application wants to perform.
* It will then create an object, which purpose is to handle that
* specific task: a Command
*
* For this example application, people can do the following tasks:
*    - add a user account to the system => handled by the UserAddCommand
* - edit a user account => handled by the UserEditCommand
* - view a list of users => handled by the UserListCommand
**/
class FrontController
{
    function run()
    {
        switch ($_GET['page'])
        {
            case 'add':
                $command = new UserAddCommand;
                break;

        case 'edit':
            $command = new UserEditCommand;
            break;

        case 'list':
            $command = new UserListCommand;
            break;
    }

    $command->execute();
    $view = $command->getView();
    $view->render();
}
}

/**
* This Command is responsible for the task of
* adding a user, and all the events that can occur while the user
* executes that task (submission of a form in this case)
*
**/
class UserAddCommand extends BaseCommand
{
    function execute()
    {
        if (!$formHasBeenSubmitted)
        {
            $this->view = new UserAddView;
            return;
        }

    if ($formIsValid)
    {
        $user = new User;
        $user->username = $_POST['username'];
        $user->password = $_POST['password'];
        $user->email = $_POST['email'];

        $user->save(); // could be $userDAO->save($user) or whatever

        $this->view = new UserHasBeenAddedView;
    }
    else
    {
        // Redisplay the form
        $this->view = new UserAddView($_POST, $formErrorMessages);
    }
}
}

class UserEditCommand extends BaseCommand
{
    function execute()
    {
        if ($userIsNotFoundInDatabase)
        {
            $this->view = new UserNotFoundView;
            return;
        }

    if (!$formHasBeenSubmitted)
    {
        $this->view = new UserAddView;
        return;
    }

    if ($formIsValid)
    {
        $user;
        $user->username = $_POST['username'];
        $user->password = $_POST['password'];
        $user->email = $_POST['email'];

        $user->save(); // could be $userDAO->save($user) or whatever

        $this->view = new UserHasBeenEditedView;
    }
    else
    {
        // Redisplay the form
        $this->view = new UserEditView($_POST, $formErrorMessages);
    }
}
}

class UserListCommand extends BaseCommand
{
    function execute()
    {
        $users = getUsersFromDatabaseSomehow();

    $this->view = new UserListView($users);
}
}

class UserAddView
{
    function render()
    {
        // Print a html form here
    }
}

class UserHasBeenAddedView
{
    function render()
    {
        echo 'The user account has been created succesfully.
        Click here to return to the main page';
    }
}

class UserEditView
{
    function UserEditView($userObject)
    {
        $this->userObject = $userObject;
    }

function render()
{
    // Print a html form here and fill up the form fields
    // with data from the $userObject
}
}

class UserListView
{
    function UserListView($users)
    {
        $this->users = $users;
    }

function render()
{
    foreach ($this->users as $user)
    {
        echo ...;
    }
}
}

So what is the better MVC approach? The latter looks more object oriented and it decouples actions/commands from controllers to allow possible reuse(though the reusability of command classes may not be obvious). However, there must be a reason why popular frameworks like Symfony, Zend, Cake and Codeigniter all choose the other approach, which simply writes each action/command inside appcontroller as methods. What do you think?

sneakyimp

The first thing that occurs to me is that the second example (FrontController) is more of a pain in the butt because for every command you want to create, you have to edit your FrontController class. This would be bad for at least a few reasons:
1) If you had multiple developers working, everyone would be fighting over the FrontController source file to add new commands. You'd probably have a lot of merges going on at some point. Basically it introduces a bottleneck of sorts in a multi dev environment.
2) In order to know which command goes to which class, you might have to take a peek inside the FrontController class to remember which class it was that goes with which command. Naming conventions help but are not always adequate.
3) It's onerous to have to edit that one file every time you want to add a new command.

These little things add up in a big project. Code maintenance requires that one extra step which takes that one extra minute which increases your cost that one extra bit that loses you the work or keeps you from going to your kid's baseball game.

Having seen CodeIgniter, I was really impressed with how intuitive the code organization is. It's pretty easy to tell from a url which class is responsible for handling it. If you want to add a new controller class to handle a new type of url request, there is no need to edit a central file to connect the url to its class so you don't have to a) make that extra code change or b) contact your project leader to ask him to check in the file so you can make the change. And, if you really want, you can define an arbitrary number of new classes that get used by your controller classes. You are in no way restricted from defining new classes until you make yourself sick.

Weedpacket

Symfony's controllers are Fowler and Zandstra's front controllers. They take requests and convert them into responses.

Of course, since they're written by individual Symfony users and not by Symfony's developers, it's the users' responsibility for how controllers are written. Nothing is stopping them from writing their controllers in the way described - but nothing forces them to, either (the developers could have for example chosen to require each Action to take a Request object as in the 'updateAction' example from the book, and required every command handler to extract what it needed from there but opted instead to leave that decision up to the user - effectively by making the command call part of the routing configuration).

Obviously, the reason there are multiple controllers is (a) to keep different areas of the site/application decoupled, and (b) since there needs to be an underlying mechanism to convert http requests into Request objects anyway, that mechanism might as well delegate the work of what would otherwise be a huge über-controller to multiple individual controllers based on routing configuration.

Lord_Yggdrasill

@ Sneakyimp:
I see what you mean, but I have to apologize to confusing you with a not-so-good example. I mean, the sitepoint's MVC is simple enough that it does not use app controller to delegate commands from front controller. In a large application, you usually have front controller sitting at the root to acquire a user request and delegate command handling to each individual app controllers. These app controllers can have various actions/commands, such as add, update, delete, view, settings or else. I was asking whether these actions should be designed as methods inside each app controller classes, or as command objects the way Martin Fowler/Matt Zandstra was suggesting. This way you do not have to modify the front controller, you only need to worry about the corresponding app controller that executes their specific commands.