How do I handle a growing Controller Class?

Question

$object_cin = new CIO( ); 
$object_cin->invoke( $_POST[ 'model' ] );

class CIO
{
    private function invoke( $model )
    {
        switch( $model ) 
        {
            case 'user_try':
                $model = new MUserTry();  
                $this->send( $model->invoke( 1 ) );
                break;
            case 'user_new':
                $model = new MUserNew( new IUniversals() , new IText(), new IMessage() ); 
                $this->send( $model->invoke() );
                break;
            case 'user_exist':
                $model = new MUserExist( new IUniversals() , new IText(), new IMessage() );  
                $this->send( $model->invoke() );
                break;
            case 'tweet':
                $model = new MTweet( new IUniversals() , new IText(), new IMessage() );
                $this->send( $model->invoke() );
                break; 
            default:
                echo "Incorrect Ajax Type provided";
        }
    }
    private function send( $string )
    {
        echo "|P|" . $string;
    }
}

Answer 1

Of course it will grow, and become impossible to maintain.

First of all, what is with the generic Control class? A website is supposed to have multiple controllers (I am assuming that it is somehow related to MVC, because that's where the term "controller" comes from), usually 1 controller per one "page" (granularity may change, depending on architectural pattern).

Next problem is the big switch statement. Each of the case's there should be a separate method in a controller. You end up repeating parts of code, just because of the design mistake.

Answer 2

You've run straight into the Fat Controller antipattern.

A controller is meant to be little more than glue logic. It passes the data from the request (GET, POST, WHATEVER) to whatever model knows how to handle it, formats whatever result the model returns and assigns it to the view to render.

At least that's what's supposed to happen.

Far too often, the developer fills the controller with the application logic, leaving the models as little more than CRUD objects for doing database access. This is not the way to develop an MVC application. Models are supposed to be "domain experts". As well as storing the data the application is working with, they are also meant to know what that data means, what is valid behaviour for given sets of data, and so on. This makes the model reusable, loosely coupled and highly coherent. You can use a rich model with many different view/controller combinations without difficultly.

If the application logic is in the controller, then you're stuck using that controller to execute the application logic, or even worse, you'll end up copying and pasting the same code into different controllers.

If the controller is full of application logic, then that's a sure sign that you need to rethink your design and refactor