真実を言うと、私は彼らのシステムを言えば、記事を書きたかったまでMVC、MVVMフレームワークは、任意の難易度を持っていないと思います。私はいくつかの問題に遭遇し、1.異なる2ノー記事は、分類のための明確な概要と枠組みの中で何も言いませんでした。私は材料の多くをチェックして、それは簡単な言葉で、フロントフレームの進化に、独自の視点に説明することでしょう。

進化の1目的

進化の目的：処理するより複雑なビュー層のシンプルな方法

非常に始まり、ビュー層では、なくても画面は非常にシンプルではありません。情報化時代の発展に伴い、それはますます複雑になってしまいます。さて、フロントページが表示層の動作を維持することは困難になる前に、古いフレームを使用している場合、これが主な理由を進化させるためのフロントエンドフレームワークであり、複雑な相互作用のロジックとユーザー多くの経験を持っています。

カテゴリー2のフレームワーク

分類フレームワーク：議論のためのフレームワークは、シナリオや歴史的背景と組み合わせる必要があります

1970年代には、MVCが生まれました。もともと代わりにWEBプログラムの、GUI（グラフィカル・インターフェース・プログラム）で使用される-このMVCのために、我々は古典的なMVCを呼び出します。以降、WEBプログラムにおけるMVCは、古典的なMVCの変異体である ;また、WEBプログラムバックエンドとフロントエンドMVC MVCは、わずかに異なるであろう。そのため、シナリオや歴史的背景を区別し、古典的なMVC WEB MVCを置くグループは非常に無責任であることを確認するために混合しないでください。

また、関係なく、MVC、MVP、MVVMとMVXの彼らの多くの亜種の、それは基本的に3層構造です。

モデル管理データとビジネスロジック
ビューのレンダリングページ
それらの間の連絡を担当するX

リコールは、私たちが記事の最初の部分で強調されていること、究極の目標の進化は、私たちは常に次のことを確認するには、この文を覚えてみましょう、ますます複雑ビュー層を満たすことです。

3. MVC

多くのMVC変異体はシナリオやいじめの歴史的背景を議論するために結合しないので、第二部では、既に、言及されています。

3.1古典的なMVC

1970で、ユーザの入力をするためにコントローラによって得られる。このときにオペレーティング・システム、及びメッセージループ、および描画する線から我々のUIシステムのも、マウスカーソルのニーズがないため、[1] 。コントローラは、ユーザの入力を取得した後、ユーザーの入力にしばらくの変更の表示レスポンス、データを修正するモデルを呼び出すに対応します。モデルデータの変更後は、ビューを通知します。ビューモニターモデル、通知されたとき、あなたのスタイルを変更します。

次のように呼び出し関係がある[2] ：

3.2 WEB MVC

私たちは、コントローラは、関係モデルを修正するために同じコールを持っている、本質的には、古典的なWEB MVCとMVCと同じである、ことがわかります。しかし、それらの間の2つの違いがあります。

コントローラからのユーザ入力は、ビューを次のようになります。ビューは、しかし、次に何をすべきか知らなくても、ユーザーの入力を処理する責任コントローラの機能の一部を着手します。それは彼女のための意思決定やハンドルのユーザーイベントを作るために、コントローラに依存しています。
「コントローラは、ユーザとシステムとの間のリンクがある」クラシックMVCではなく、WEB MVC、表示変更の両方委託コントローラモデルでは、また、独立したユーザイベントを処理することができます：コントローラの役割は小さいです。古典的なMVCでは、コントローラはほとんど行うためになされたもので、WEB MVCシステムでの作業の一部である別のユーザー入力ビューに配布されます。[3]このように、WEB MVCでは、コントローラは、わずか数入力検証薄くなると作業をルーティングします。

3.3 MVCの利点と欠点

利点：

ビジネスロジックとプレゼンテーションロジックの分離、モジュール性の高いです。アプリケーション・ロジックは、ビジネスロジックとプレゼンテーションロジックを変更せずに、変更する必要があるときに、唯一の行に別のコントローラコントローラを交換する必要があります。
Observerパターンは、複数のビューを更新し、同時に行うことができます。

短所：

コントローラーのテスト難しいです。ビュー同期動作が見る自分自身で実行されるため、およびビューは、UI環境の存在下で実行します。ビューがアサート更新でき、モデルの更新：UI環境の非存在下におけるコントローラユニットテストのための時間は、アプリケーション・ロジックはの正しさを検証することができません。
コンポーネント化ではない見ます。ビューは、特定のモデル、このビューなど、必要に応じて困難うちに再利用可能なアセンブリの更なる用途に強く依存します。ドメインモデルの異なるプログラムが同じではないので。[1]

4. MVVM

4.1 MVVM

前任者の前のおかげで、我々はMVP段階での滞在をより行いますが、MVVM段階への大きな一歩ませんでした。実際には、MVPとMVVMの間の主な違いは、結合双方向のデータがあるかどうかです。利害関係者は、「見ることができる分析MVC、MVPとMVVMの類似点と相違点自己理解を」。

3.2では、私たちは、ページ上の唯一のボタンは、今ではなく、1000個のボタンがあり、MVCのコンポーネントではないので、それぞれがまた表示、その後、別のDOMオブジェクトを操作し、想像し、簡単なMVCの実装しましたロジックは非常に複雑で、維持が困難になります。この問題を解決するために、MVVMはされて入ってきました。

ビューのユーザ対話、ユーザイベント・トリガ、ビュービューモデルロジック呼び出し応答対応するイベント・タイプと、層モデリングう呼び出しインターフェースに、適切な処理の後に行わ応答論理ビューモデルで、呼び出すことを実装するインタフェース、モデル層を得これに対応するデータ変更イベントをトリガするデータの変更、; ViewModelには、データの状態を変更することであろうプレゼンテーションロジックViewModelに、新しいモデルデータを取得し;ステータスデータ内のViewModelの変化、そして最終的につながるイベントのViewModelモジュールはを聞いてきました変換の状態を表示し、我々は、ユーザーイベントへの応答を完了しました。
画像のキャプション

4.1 MVVMの長所と短所