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

当然它会增长，而且无法维持。

首先，通用Control类是什么？一个网站应该有多个控制器（我假设它与MVC有某种关系，因为这就是术语“控制器”的来源），通常每个“页面”有1个控制器（粒度可能会改变，具体取决于架构模式）

下一个问题是大switch语句。 case中的每一个都应该在控制器中有一个单独的方法。你最终会因为设计错误而重复部分代码。

Answer 2

你直接进入Fat Controller反模式。

控制器只不过是胶合逻辑。它将来自请求（GET，POST，WHATEVER）的数据传递给任何知道如何处理它的模型，格式化模型返回的任何结果并将其分配给要呈现的视图。

至少那是应该发生的事情。

开发人员经常使用应用程序逻辑填充控制器，使模型只是用于进行数据库访问的CRUD对象。这不是开发MVC应用程序的方法。模型应该是“领域专家”。除了存储应用程序正在使用的数据之外，它们还意味着知道数据意味着什么，给定数据集的有效行为是什么，等等。这使得模型可重用，松散耦合并且高度一致。您可以毫不费力地使用具有许多不同视图/控制器组合的丰富模型。

如果应用程序逻辑在控制器中，那么您将无法使用该控制器执行应用程序逻辑，或者更糟糕的是，您最终会将相同的代码复制并粘贴到不同的控制器中。

如果控制器充满了应用程序逻辑，那么这肯定表明您需要重新考虑您的设计和重构

如何处理不断增长的控制器类？

2 个答案: