$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;
}
}
2 に答える
もちろん、それは成長し、維持できなくなります。
まずジェネリックControl
クラスとは?Web サイトには複数のコントローラーがあるはずです (「コントローラー」という用語が由来するため、MVC に何らかの形で関連していると想定しています)、通常は 1 つの「ページ」ごとに 1 つのコントローラー (アーキテクチャーのパターンに応じて粒度が変わる場合があります) .
次の問題は大きなswitch
声明です。のそれぞれがcase
、コントローラーに個別のメソッドを持つ必要があります。設計ミスが原因で、コードの一部を繰り返すことになります。
Fat Controllerアンチパターンに直接遭遇しました。
コントローラーは、グルー ロジックにすぎません。リクエスト(GET、POST、WHATEVER)からのデータを、それを処理する方法を知っているモデルに渡し、モデルが返す結果をフォーマットし、ビューに割り当ててレンダリングします。
少なくともそれが起こるはずです。
あまりにも多くの場合、開発者はコントローラにアプリケーション ロジックを詰め込み、モデルをデータベース アクセスを行うための CRUD オブジェクトにすぎないようにしています。これは、MVC アプリケーションを開発する方法ではありません。モデルは「ドメインの専門家」であると想定されています。アプリケーションが処理するデータを保存するだけでなく、そのデータが何を意味するか、特定のデータ セットに対して有効な動作は何かなどを知ることも目的としています。これにより、モデルが再利用可能になり、疎結合になり、一貫性が高くなります。多くの異なるビュー/コントローラーの組み合わせでリッチ モデルを問題なく使用できます。
アプリケーション ロジックがコントローラー内にある場合、そのコントローラーを使用してアプリケーション ロジックを実行することはできません。さらに悪いことに、同じコードを別のコントローラーにコピー アンド ペーストすることになります。
コントローラーがアプリケーション ロジックでいっぱいになっている場合は、設計を再考してリファクタリングする必要があることを示しています。