model-view-controller - MVC は何のために発明されたのですか?

Question

私は Web 開発の初心者で、MVC に関する wiki やディスカッションを読んでいます。ただし、読めば読むほど、その設計目的について混乱が生じます。

なぜこのデザインパターンが発明されたのか知りたいのですが？そして、それはどのような問題を解決するために使用されますか?

前もって感謝します。

Answer 1

MVC パラダイムの目標は、本質的にコードの分離の形式を確保することです。コードを開発するときによく発生する問題は、コードが連続して記述され、各部分が別の部分に続き、各部分が他の部分の実行内容に直接依存することです。

大規模なプロジェクトで作業する場合、コードの保守とさらなる開発がすぐに問題になる可能性があります。したがって、MVC パラダイムがやろうとしていることは、プレゼンテーション ロジック (結果を表示するコード) からビジネス ロジック (実行するコードなど) を確実に分離することであると簡単に言えます。ただし、これら 2 つの部分は相互に通信する必要があり、これはコントローラーが担当します。

これにより、さまざまな部分がより分離されたコードの明確な構造が可能になり、相互の依存が少なくなります。

分離はまた、よりモジュール化された方法で作業することを意味します。つまり、各パーツがインターフェイス (他のパーツを呼び出すために使用されるいくつかの定義済み関数と変数) を介して他のパーツと対話するため、基本的な機能を変更することなく、基本的な機能を変更できます。インターフェイスが同じままである限り、コードの他の部分を変更します。

したがって、解決しようとしている問題は、コードを壊さずに何も変更または追加できないほど絡み合ったコードベースを避けることです。つまり、元のコードを作成した場所以外のあらゆる場所でコードを変更する必要があります。変化します。

Answer 2

ある程度、それは問題を探すための解決策です。

かなり古いプログラマーとして、私は「関心の分離」の利点をよく知っていますが、(私の控えめな意見ではありますが) MVC は、特に「クックブック」ファッションを実装した場合、これをあまりうまく行いません。非常に多くの場合、機能ごとに 3 つの個別のモジュールがあり、複雑さを最小限に抑えて信頼性と保守性を最大化するという真の目標を達成するための共通のコードや共通のテーマがなく、モジュールの急増につながるだけです。

「クラシック」MVC は、たとえば、データベース テーブルの管理が、対応するテーブル ビューの管理と密接に関連している可能性がある、典型的な電話 GUI アプリでは特に不適切です。ロジックを 3 つの異なるモジュールに分散させることは、物事をより複雑にし、保守を難しくするだけです。

多くの場合、うまくいくのは、データについて考え、どのような種類の更新とクエリが必要になるかを理解してから、データベース (または使用するデータ ストレージ) の「ラッパー」を構築し、それを「抽象化」して相互作用を最小限に抑えることです。 DB とシステムの残りの部分の間。しかし、これを計画するのは難しく、かなりの量の試行錯誤が必要になることがよくあります。

同様に、他の領域を抽象化できる場合もありますが、たとえば GUI インターフェースを抽象化することは、多くの場合、難しすぎて価値がありません。

データベース、GUI システム、アプリ フロー制御メカニズムなどの作成者は、これらのインターフェイスを抽象化するためにすでにかなりの労力 (場合によっては過度に) を費やしていることに注意してください。 （特に料理本のアプローチをとる場合）。

Answer 3

Model View Controller は、寄せ集めを 1 つの BLOB にまとめるのではなく、コード内の懸念事項を分離するために作成されました。(スパゲッティ コード) ビュー コードは単なるプレゼンテーション ロジックです。モデルはドメインを表すオブジェクトであり、コントローラーはビジネス ロジックとバックエンドのサービスへの統合をネゴシエートします。