MVCフレームワークに関するオンラインディスカッションを読んでいると、Java / .NET開発者からCake、Code Igniter、SymfonyなどのPHPプロジェクトに向けて、「これらは巧妙なハックですが、真のMVCではありません」というコメントがたくさん寄せられています。
つまり、何かを「真の」MVCフレームワークにするのは何ですか。つまり、Cake、Code Igniter、Symfonyなどとは異なる動作をする.NETまたはJava MVCフレームワークの例は何ですか？また、それらの異なる動作は何ですか？ブートストラップを必要とする強制的なオブジェクト指向がPHPにないだけなのか、それとも他の何かなのか。
PHPが言語を「吸う」理由を知っています。私は、MVCの実装や使用の違いにもっと興味があります。
MVCの考え方は、アプリケーションアーキテクチャを3つの独立した層に分離し、これらの各層が他の層に影響を与えることなく異なる実装を使用できるようにすることです。ほとんどの場合、ビジネスロジック（モデル）とプレゼンテーション（ビュー）が区別されます。
多くのPHPフレームワークは、「意見のあるソフトウェア」というRuby on Railsの哲学を使おうとしているため、モデルとビューが正しく機能するには、両方が特定の実装に準拠している必要があります。つまり、クラスには特定の名前を付ける必要があり、プロジェクト内のファイルは特定のディレクトリ構造に従って編成する必要があり、Viewスクリプトの表記は規則に従う必要があります。
これにより、各層の異なる実装を個別に置き換えることが困難になります。これは、層を相互に分離するというMVCの目的に反します。
フレームワークが適切で真実であるかどうかを確認するのに役立つ可能性のあるいくつかの質問があります。
そして、これはユニットテストを書かなくても当てはまります。
フレームワークから独立してMVC関連のコードを記述できるはずです。アプリケーションがフレームワークから何らかの入力を受け取る場合、それは既知のインターフェースを持つオブジェクトである必要があり、具体的なクラスではありません。
本当のMVCフレームワークは、アーキテクチャ自体に影響を与えない（または非常に制限される）ということです。せいぜい、それはアプリケーション呼び出しがMVCトライアドに到達するための明確で簡単な方法を提供するだけです。そして多分あなたに便利さを提供します..制限や制約ではありません。
フレームワークによって提供されたすべてのクラスを拡張できるはずです。また、実装する必要のある機能を簡単に理解できる必要があります。
「何かが起こった」場合、これを行うのは非常に困難になります。これは通常、フレームワークのコードのグローバル状態を指します。静的メソッドまたはグローバル/静的変数のいずれかの形式。
コントローラがどこでどのように実行されるかを見つけることができますか？通常、それはそれほど簡単ではありません。その神秘的なポイントは通常、オブジェクトグラフの奥深くにあります。時には拡張クラスでも。
このような状況では、コントローラーが実行された環境を変更するのが非常に困難になります。また、コントローラーメソッドがどのように見えるかについての厳密なルールを課します。
これはすべて、真のMVCフレームワークでは、オプションを制限するのではなく、開発プロセスを強化する必要があるという点に戻ります。
承認の認証は開発の別の側面のように見えるかもしれませんが、実際には、MVCのコンテキストでは、それはややトリッキーになる傾向があります。
多くのフレームワークには、いくつかの認証/承認インフラストラクチャがあります。これは反復的な作業であり、私たち全員がそれを死に至らしめたので、フレームワークが提供できる機能の良い候補です。
しかし、ここにキッカーがあります。それらのほとんどは、コントローラー内に認証を入れようとし、それをどのように調整できるかについて非常に慎重です。これは別の制限です。
これは結局のところこれです。どのフレームワークでも、ログイン機能を追加するためだけにすべてのコントローラーを書き直す必要はありません。OCPの違反を無視したとしても、これはあなたが誤って何かを忘れてしまうという別のリスクを追加するだけです。
..私の2セント
このwikiページが役立つかもしれません。
Cakeとほとんどの「MVC」フレームワークは、「パッシブビュー」MVCと呼ばれるものです。ここに説明する素晴らしい記事があります：http： //www.martinfowler.com/eaaDev/PassiveScreen.html
真のMVCフレームワークには、M（odel）レイヤーがありません。CakePHPとその仲間たちは、データベースにアクセスするための巧妙なクラスをいくつか持っています。これをModelと呼び、データ処理の大部分をコントローラーに任せています。
それは間違いです。モデルはすべてのデータ処理を実行する必要があり（そのためにデータベースクラスの支援を使用できます）、コントローラーはユーザー/Webページとモデルの間のゲートウェイである必要があります。ほとんどの場合、モデルはルールに準拠していない単純なPHPオブジェクトであるため、フレームワークはそれらのルールを指定できません。
時々、人々は一歩下がって、デジタル世界がその用語の由来となった実際の「フレームワーク」を見る必要があります。それは、個人的な議題に合うように言葉を歪め、他のシステムを軽視する無限のオンラインオプションにもかかわらず、それが意味することを説明するのに役立つかもしれません。
フレームワークは、作業のあらゆる分野で役立つはずです。
したがって、ポートフォリオページが1つしかない場合は、必要なツールのセットはごくわずかです。次のFacebookを開始すると、「フレームワーク」は大きく異なります。
フレームワークは、その名前が示すように、構造（この場合はアプリケーション）をサポートすることを目的としています。ほとんどのフレームワークに共通する（そして悲しい）ことは、フレームワーク自体が印象的な構造になり、ビジネスロジック、プレゼンテーション、ルーティング/制御を分離する独自の方法を指示することです。1年前に書いたものを維持するためだけに、チーム全体が必要なように見えるアプリケーションコードが表示されます。目的はフレームワークの機能の豊富さであるように思われます。いいえ、ちがいます。それは、アプリケーションのどのコンポーネントを分離する必要があり、どこで分離する必要があるかをプログラマーが自由に決定できるようにすることです。タスクを、独自の専門知識を持つ個人のワークグループに分散できる限りです。
モデル、ビュー、コントロールを分離する必要があるかどうか（ちなみに、どこかで相互に通信する必要があります）は、ソリューションアーキテクトがぼかしまたは区別を決定する必要があります。
JavaServer Facesは、MVC用の非常に優れたフルスタックフレームワークです。優れたViewコンポーネント、マネージドBeanを備えた優れたコントローラーがあり、モデルに対してビジネスクラスを作成できます。