MVCパターンを使用する必要があるのはなぜですか？

最近、Webアプリケーションを実行している人はすべてにMVCを使用したいと考えています。ただし、このパターンを使用するように説得することは困難です。一般的な考え方は、プログラムを表すフロントエンドからバックエンドロジックを分離することだと理解しています。一般的に、ビューは常にある程度コントローラーに依存しているようで、最終的にはモデルに依存します。コントローラーを追加することで得られる利点がわかりません。「これがアプリケーションの設計方法だ」という誇大広告をたくさん読んだことがありますが、どこに行くべきかがまだわからないかもしれません。私がMVCについて他の人と話すときはいつでも、誰がどのカテゴリに属する​​かについて異なる考えを持っているようです。

それでは、なぜMVCを使用する必要があるのですか？フロントエンドをバックエンドロジックから分離するだけでMVCを使用すると、何が得られますか？（このパターンのほとんどの「利点」は、インターフェイスを実装から分離するだけで得られ、別の「コントローラ」を持つ目的を説明できません）

へえ。Martin Fowlerは、MVCについてのあなたの混乱に同意します。

MVCにはパターンが非常に多く含まれているため、MVCをパターンとして考えることはそれほど有用ではありません。さまざまな場所でMVCについて読んでいるさまざまな人々が、さまざまなアイデアを取り入れて「MVC」と表現しています。これで十分な混乱が生じない場合は、中国のささやきのシステムを通じて発生するMVCの誤解の影響を受けます。

しかし、彼はMVCの動機についてより説得力のある説明の1つを続けています。

MVCの中心にあるのは、分離プレゼンテーションです。分離プレゼンテーションの背後にある考え方は、現実世界の知覚をモデル化するドメインオブジェクトと、画面に表示されるGUI要素であるプレゼンテーションオブジェクトを明確に分けることです。ドメインオブジェクトは完全に自己完結型であり、プレゼンテーションを参照せずに動作する必要があります。また、複数のプレゼンテーションを、おそらく同時にサポートできる必要があります。

ファウラーの記事全体はこちらで読むことができます。

これはあなたが取り組んでいる問題に大きく依存していると思います。私は次のように分離を見ています：

モデル -データをどのように表現しますか？たとえば、オブジェクトからDBなどの永続ストレージに移動するにはどうすればよいですか？>「ユーザー」オブジェクトをデータベースに保存するにはどうすればよいですか？

コントローラー -私は何をしていますか？これが行われているアクションであり、概念レベルで実行する必要があるものです。たとえば、ユーザーに請求するにはどの段階を経る必要がありますか？NBこれは、あらゆる量のオブジェクトに影響を与える可能性がありますが、DBに永続化される方法については何も知りません。

ビュー -結果をどのようにレンダリングしますか？

私が見ている問題は、多くのWebアプリケーションがDBへのCRUD（作成-取得-更新-削除）インターフェースを称賛していることです。つまり、コントローラーは「ユーザーを追加する」ように指示され、モデルに「ユーザーを追加する」ように指示します。何も得られません。

ただし、実行するアクションがモデルの変更に直接適用されないプロジェクトでは、コントローラーを使用することで作業がはるかに簡単になり、システムのメンテナンス性が向上します。

してはいけません。

言い換えさせてください。ビューからロジックを分離するアーキテクチャを使用する必要があります。モデルに必ずしも適合しないロジックが必要な場合（たとえば、URLチャンクを解析するツリートラバーサルなど）、コントローラー（MVCなど）を使用するアーキテクチャを使用する必要があります。

CIとYiiから来て、専用のコントローラーを持つことは本当にクールなアイデアだと思いました。ただし、適切なRESTfulインターフェースを備えたアプリケーションを開発する場合、モデル固有でないロジックを処理するコントローラーの必要性は少なくなるようです。したがって、Djangoに移動してからPyramid（どちらもMVCアーキテクチャに完全に準拠していない）に移行すると、コントローラーは実際に作成中のアプリケーションに必要なコンポーネントではないことがわかりました。どちらのフレームワークにもPyramidでのURLディスパッチなどの「コントローラーっぽい」機能がありますが、これは設定の問題であり、ランタイムの問題ではありません（YiiのCControllerなど）。

結局のところ、本当に重要なのは、ビューをロジックから分離することです。これにより、実装の面で問題が解決されるだけでなく、FE / BEエンジニアが並行して作業できるようになります（チーム環境で作業する場合）。

（サイドノート：私は専門的にウェブアプリを開発していませんので、欠けているものがあるかもしれません）

はい、これに関する用語は混乱です。言葉で誰かが何を意味しているのか決して理解できないので、話すのは難しいです。

別のコントローラーを使用する理由については、その理由は、どのバージョンのコントローラーについて話しているかによって異なります。

テストを実行すると、ビューには、作成しておらず、おそらくテストしたくないウィジェットが多数あるため、コントローラーが必要になる場合があります。はい、実装を継承から分離したので、スタブまたはモックを使用して他のものをテストできますが、具体的なビュー自体をテストする場合は難しくなります。同じコードを実行するウィジェットを持たないコントローラーがあれば、それを直接テストすることができ、スクリプトでウィジェットをテストする必要はないかもしれません。

他のバージョンは、具体的な利点を示すのがより困難です。私はそれはほとんど懸念事項の分離の問題だと思います-GUIに適用されるがビジネスモデルの一部ではないロジックから純粋な視覚GUI懸念を分離します（たとえば、ウィジェットの表示すべきモデルからの更新を変換します）。しかし実際には、2つのクラスは非常に密に結合されているため（インターフェイスを介して通信する場合でも）、ビューにマージすることに過度に動揺することは難しく、機能がより再利用可能になる方法に注意してくださいそれらが分割された場合。

簡単に言えば、懸念の分離。物事の「正しい」方法、よりクリーンなコードなどについてのすべての話とは別に、MVCを使用するとコードをより簡単に再利用できると言えます。基本的に、モデルとコントローラーをプログラムし、Webアプリ、デスクアプリ、サービスなど、どこでも多くの労力をかけずにそれらを使用できます。

まあ、MVC構造を使用する基本的な理由は、単一の作業プロセス、単一のモデルを使用して任意のアプリケーションを開発する業界の設定に現れます。そのため、プロジェクトが組織のあるモジュールから別のモジュールに移動する場合、作業シナリオをよりよく理解するのがはるかに簡単です。作業の明快さが組み込まれています。
個人はアプリケーションに対して異なるアプローチをとるので、アソシエイトと組み合わせて作業する場合、まず2人（あなたとあなたのアソシエイト）が共通に合意したモデルについて話し合って着地します。そしてそのような場合、それはあなたとあなたの同僚にそれぞれ割り当てられた責任を明確なマージンで分けます。

MVCは、マネージャーである理論家によって単なる流行語として使用されていると思います。ただし、HTML5が普及しているレスポンシブデザインを使用したWebの現在の反復、およびWebとiPhoneで機能するデータベースプログラミングの単一行を作成しようとすることは、MVCの一般的なアイデアに役立ちます。Webフロントエンドテクノロジーは文字どおり、CSSコントロールの新しい反復であるJqueryで文字通り光の速度で動いていますが、サーバー側のものはカタツムリのペースで動いています。

最終的に、サーバー上のすべてのものは、フロントエンドにデータを送り込むサービスまたは「アプレット」になり、使用しているクライアントの種類に応じて、データの消費と表示が異なります。その意味で、MVCは理にかなっています。

この点で、私は現在の現実の世界では、MVVMは実際にはコントローラーよりも優れた「パターン」またはそれを呼び出すものであると考えています。 。MVVMパターンでは、ViewModelはビューを即座に更新できます。さらに、MVVMモデルはRESTfulデザインプリンシパルIMHOを促進します。