なぜMVCパターンを使用する必要があるのですか？
今日、Webアプリケーションを実行しているすべての人が、すべてにMVCを使用することを望んでいるようです。ただし、このパターンを使用するように自分を説得するのは難しいと思います。私は、プログラムを表すフロントエンドからバックエンドロジックを分離するという一般的な考え方を理解しています。一般的に、ビューは常にある程度コントローラーに依存しているようですが、それは最終的にモデルに依存します。コントローラーを追加することでどのような利点があるのかわかりません。 「これがアプリケーションの設計方法だ」という誇大広告を読んだことがあるのですが、どこに何をすべきかわからないのかもしれません。私がMVCについて他の人と話すときはいつでも、何がどのカテゴリに属しているかについて誰もが異なる考えを持っているようです。
では、なぜMVCを使用する必要があるのでしょうか。 MVCを使用して、フロントエンドをバックエンドロジックから分離するだけで何が得られますか？ （このパターンについて私が見るほとんどの「利点」は、インターフェースを実装から分離することによって得られ、別個の「コントローラー」を持つことの目的を説明することに失敗します）
へえ。 Martin FowlerはMVCについてのあなたの混乱に同意します：
MVCにはかなりの数の異なるアイデアが含まれているため、パターンとしてMVCを考えることはそれほど役に立ちません。さまざまな場所でMVCについて読んでいるさまざまな人々は、そこからさまざまなアイデアを取り入れ、これらを「MVC」と表現しています。これが十分な混乱を引き起こさない場合は、中国語のささやきのシステムを通じて発生するMVCの誤解の影響を受けます。
ただし、MVCの動機についてより説得力のある説明の1つを続けます。
MVCの中心には、分離プレゼンテーションと呼ばれるものがあります。 Separated Presentationの背後にある考え方は、現実世界の認識をモデル化するドメインオブジェクトと、画面に表示されるGUI要素であるプレゼンテーションオブジェクトを明確に区別することです。ドメインオブジェクトは完全に自己完結型であり、プレゼンテーションを参照せずに機能する必要があります。また、おそらく同時に複数のプレゼンテーションをサポートできる必要があります。
Fowlerの記事全体 here を読むことができます。
これはあなたが取り組んでいる問題に大きく依存していると思います。私は次のように分離を見ます：
モデル-データをどのように表現しますか？たとえば、オブジェクトからDBなどの永続ストレージに移動するにはどうすればよいですか->「ユーザー」オブジェクトをデータベースに保存するにはどうすればよいですか？
Controller-私は何をしていますか？これが行われているアクションであり、概念的なレベルで何を実行する必要があるかです。たとえば、ユーザーに請求するためにどの段階を通過する必要がありますか？ N.B.これはオブジェクトの量に影響を与える可能性がありますが、オブジェクトがDBにどのように保持されるかについては何も知りません。
View-結果をレンダリングするにはどうすればよいですか？
私が目にしている問題は、多くのWebアプリケーションがDBに対する栄光のCRUD（Create-Retrieve-Update-Delete）インターフェースであることです。つまり、コントローラーは「ユーザーを追加する」ように指示され、次にモデルに「ユーザーを追加する」ように指示するだけです。何も得られません。
ただし、実行するアクションがモデルの変更に直接適用されないプロジェクトでは、コントローラーによって寿命が大幅に容易になり、システムがより保守しやすくなります。
すべきではない。
言い換えましょう。ロジックをビューから分離するアーキテクチャを使用する必要があります。必要に応じて、必ずしもモデルに適合しないロジック（たとえば、ツリートラバーサル解析URLチャンクなど）が必要な場合は、コントローラー（MVCなど）を利用するアーキテクチャを使用する必要があります。
CIとYiiから来て、専用のコントローラーを用意するのは本当にクールなアイデアだと思いました。ただし、適切なRESTfulインターフェースを使用してアプリケーションを開発する場合、モデル固有でないロジックを処理するコントローラーの必要性は少なくなるようです。したがって、Django=に移動してからPyramid（どちらもMVCアーキテクチャに完全に準拠していない）に移動すると、実際には、コントローラーが私が構築しているアプリケーションに必要なコンポーネントではないことがわかりました。フレームワークには、PyramidでのURLディスパッチなどの「コントローラっぽい」機能がありますが、これは構成のことであり、ランタイムのことではありません（YiiのCControllerなど）。
結局のところ、重要なのは本当にロジックとビューの分離です。これにより、実装に関してクリーンアップが行われるだけでなく、FE/BEエンジニアが並行して作業できるようになります（チーム環境で作業する場合）。
（補足：Webアプリを専門的に開発しているわけではないので、足りないものがあるかもしれません）
はい、これに関する用語は混乱しています。あなたが誰かによってかなりのこと手段をまったく意味しないので、話すのは難しいです。
なぜ別のコントローラーであるかという限り、その理由は、コントローラーのバージョンによって異なります。
テストを実行すると、ビューには、作成していない、おそらくテストしたくないウィジェットがたくさんあるため、コントローラーが必要になる場合があります。はい、実装を継承から分離したため、スタブまたはモックを使用して他のものをテストできますが、具体的なビュー自体をテストする場合は難しくなります。 されなかったであるコントローラーに同じコードを実行しているウィジェットがある場合は、それを直接テストできます。スクリプトを使用してウィジェットをテストする必要はないかもしれません。
他のバージョンは、具体的な利点を示すのが私見では難しいです。私はそれが主に懸念の分離の問題だと思います-GUIに適用されるが、ビジネスモデルの一部ではないロジックから純粋なビジュアルGUIの懸念を分離します（ウィジェットの表示が必要なモデルから更新を変換するなど）。しかし実際には、2つのクラスは（インターフェースを介して通信する場合でも）緊密に結合されている可能性が高く、それらをビューにマージすることに過度に混乱することは難しく、機能がより再利用可能な方法に注意する必要があります。それらが分割された場合。
簡単に言えば、懸念の分離です。 「正しい」方法の実行、コードの整理などに関するすべての話は別として、MVCを使用すると、コードをより簡単に再利用できると言えます。基本的には、モデルとコントローラーをプログラミングして、Webアプリ、デスクアプリ、サービスなど、どこにでも簡単に使用できます。