はじめに
筆者が初めて MVC に触れたのは Java でした。ssh などの大規模なものではなく、単なる階層化開発で、コード構造をより明確にするためでした
-
V（View）Java では swt、swing で作成された GUI になり得ます。もちろん、jsp で生成されたページ也可以是
View は純粋なインターフェースで、ユーザーにデータを友好的な形式で表示する責任があります
-
M（Model）は純粋な Java Bean（単純な Bean、カスタムデータ構造と getter/setter のみ）也可以是、いくつかのデータ検証ロジックを含むこともできます
データ検証ロジックを V または C 内に配置するものもあり、具体的なシナリオによります。例えば jsp アプリケーションではデータ検証ロジックを V 内に配置するのが適切で、リクエストを減らすことができます
-
C（Controller）はビジネスロジックが集約される層で、すべての重要なビジネスロジックが C 内にあります
C は V から渡されたユーザー入力を受け取り、処理完了後に M を更新し、M が V に更新を通知します。1 つの V が 1 つの C に対応（依存）することも、複数の V が 1 つの C に対応することもできます（複数のページのビジネスロジックが基本的に同じ場合）。しかし、1 つの V が複数の C に対応すべきではありません。なぜなら、この依存関係は密結合になるからです。M と V の対応関係は実装方法によります。古典的なオブザーバーパターンかパブリッシュ/サブスクライブパターンかの違いで、前者は M が直接 V に更新を通知し、後者は M が C を通じてのみ V を更新できます
後で、データベース操作（C に置く？）や設定データ/定数（V に置く？）など、どこに配置しても適切でないロジックがあることに気づきました。そこで Core を追加して定数を配置し、DAO 層を設けてデータベース操作を配置し、これらすべてを C の補助層としました
MVP と MVVM の理念はこれとは異なり、層を増減するのではなく、層の役割を再分割したもので、もちろん、再分割後に他の補助層も追加されました
一.MVC
入力から出力まで、データフロー（無理やりデータフロー図と呼びましょう。阮はこれを通信方式図と呼んでいます）は以下の通りです：
[caption id="attachment_730" align="alignnone" width="889"]
MVC 数据流 [/caption]
注意：これは依存関係図ではありません。依存関係から見ると、M と V はオブザーバーパターンの関係で、V が M に依存するはずです（Observer は Subject の存在とその公開インターフェースを知っている）。M は V に依存しません（Subject は誰が自分を关注しているか知らず、気にもしません）。相互作用関係（データフロー）から見ると、M が V を更新します（Subject が変化すると、自動的にすべての Observer に通知されます）。V は直接 M を更新する方法がありません。
依存関係は具体的な実装によります。個人的には Trygve Reenskaug の当初の実装にこだわる意味はないと考えています。したがって依存関係図は描けません。しかも何年後には上記のデータフロー図も間違っているかもしれません。当初の C がユーザー入力を受け取るものから、現在の V も受け取れるものまで、将来の変化は誰が知っているでしょうか？
（余談：これが winter と阮の相違点です。阮眼中的な MVC は広義のもので、一種の階層化思想です。一方 winter は MVC は 79 年のもののことで、その他はすべて MVC とはみなせないと考えています。。。2 つのブログ記事は底部の参考資料にすべてリストされています。興味があれば見に行ってください）
（蛇足：1979 年に Trygve Reenskaug が MVC を提案しました。これが本物と言われています。当時ユーザー入力は C のみで取得でき、V の機能は非常に弱く、入力ボックス上のカーソルでさえ C が V に描画を制御していました。したがって C は 1 つのみ存在でき、すべてのロジックは C を経由する必要があると規定されました。煩雑なインターフェース表示を制御しやすくするためです。現在ではユーザー入力は V で直接取得でき、カーソルの描画などの作業はオペレーティングシステムが自動的に完了します。C が 1 つのみ存在できることに固執するのは完全に愚かです）
###Backbone.js
backbone はフロントエンド MVC のフレームワーク例で、MVC 実装と基本ツールを提供し、自由度が非常に高いです。実際のアプリケーションでは他のツールと組み合わせる必要があります。例えば underscore、jQuery/zepto は必須品です
Backbone は脊椎で、最も重要なフレームワーク実装のみを提供し、残りの部分は非常に自由であることを示しています。Backbone の詳細情報については、底部の参考資料をご覧ください
二.MVP
当初の MVP 図は以下の通りです：
[caption id="attachment_731" align="alignnone" width="690"]
mvp[/caption]
MVC と比較して、最大の区别は C が P（Presenter）に改名されたことではなく、M から V への線が 1 つ増えたことでもありません。ちょっと待ってください。オブザーバーパターンではありませんでしたか？なぜ M が直接 V にアクセスできるのですか（Subject が直接 Observer にアクセスできる）？後で議論します。最も重要な区别はP は単一のオブジェクトではなく、図中の interactor、command および selection を合わせたものが P と呼ばれる、つまり P は存在せず、P は「interactor、command および selection」に分解されたことです
本来の M と V のオブザーバー関係の下では、V は直接 M にアクセスできず、C 経由で伝達するしかなく、使いにくかった（おそらく効率または使いやすさの点で）。その後 V を強化し、V が直接 M にアクセスできるようにしました（V がユーザー入力を受け取れることも強化です。当初の MVC では C のみでユーザー入力を取得でき、ユーザーは直接 C と対話していました。カーソルや入力文字などは C が V に表示を制御していました）。そして C を P に改名し、MVC と区別しました。実際には M（太った V）C でも構いません。V が厚くなれば、C は薄くなります（単純なデータ表示は V に任せ、直接 M のデータを取得して表示します（データとビューのバインディング？）。もちろん、上記の図から V は M を読むことしかできず、書き込みは C 経由で行う必要があることがわかります）。したがって、P は一種の C であり、正確にはより薄い C だと言う人もいます
MVP には適切な例フレームワークがありません。MVP に対する理解に論争があるためです。一部の記事では P は強化された V だと言い、また P 内には表示ロジックのみが配置されていると言います。。。ではビジネスロジックはどこに配置するのですか？単に Presenter という字面から理解し、当然のように解釈してはいけません
（MVP は 1996 年に提案されました。1979 年の MVC はすでに適切でないと考える人がいたためです。MVC の理念は依然として存在しますが、当初の硬直したルール、例えば C は 1 つのみ、C のみでユーザー入力を取得できるなどの概念は時代遅れになりました。MVP 自体も過渡の産物かもしれません。有用なのは背後の理念のみです。例えば階層化開発、モジュール化、イベント駆動などです）
三.MVVM
MVVM はマイクロソフトが WPF を推出した際に提案されたパターンです。WPF の特徴は強力なコントロールで、例えば DataGrid は直接データテーブルとバインディングでき、単純なデータテーブル表示の作業量を大幅に削減します。wpf の View は XAML で定義され、コントロールの基本機能、例えば入力データ検証は、簡単な XAML 設定で実現できます。これが MVVM の最大の特徴です：V と M の双方向バインディング
MVVM の利点は V をさらに分離し、V が別の言語（XAML）で記述されることさえあるため、コントロールの再利用性を大幅に強化します。前のプロジェクトのカスタムコントロールの XAML コードをそのまま持ってきて使用でき、元のプロジェクトからロジックコードを注意深く剥離する必要がありません
winter が提示した図は以下の通りです：
[caption id="attachment_732" align="alignnone" width="690"]
mvvm[/caption]
つまり、MVVM 内の V は非常に強力で、非常に完成されており、非常に厚い V です。この V = V + C + E だからです。データバインディングについては、使用の角度から見ると V と M がバインディングされています。例えば TextBox の値は自動的に Model データと同期されます。上記の図から見ると V と VM 間のデータバインディングで、VM は「コマンド」を通じて V を操作できます。例えば xx.close() などです。より詳細な説明は以下の通りです：
如何呈現是 view 的事，調用方只用給 view 一個 data，view 就只負責這個 data 的顯示，調用者不用管 view 如何顯示，只負責將 data 傳遞，view 也不用管數據從何而來，只要將 data 以自己的方式呈現，并且時刻關注 data 的變化如何反映到 view 上來就好。
而雙向綁定，則是一個附加產品，畢竟只有像 textbox,form 等會改變數據的 UI 不多，大部分 UI 都只是單向的呈現數據而已。不過有雙向綁定在，則可以將 view 和調用方分離得更徹底，即獲取數據不必在意特別的 view，如一個日期是用戶在 textbox 中輸入，還是用 calendar 選取的無關緊要，因為那是 view 設計和安排的事。
###Angular.js
Angular の MVVM はほぼ公认的です。MVVM の特徴は重さです。wpf が使いやすいのは一整套の強力な常用コントロールを提供しているためで、想像できる通りです
Angular の詳細情報については Angular 公式サイト をご覧ください。Angular は Google が作成したもので、おそらく MVC の発展方向でしょう
四.MV* フレームワークの選択
不建议直接将业务库框架直接取来使用，更不建议使用过重的业务框架，最好是能明白框架想要解决的问题，与自己项目的实际需求，自己造轮子知根知底。
（浅谈移动前端的最佳实践 より引用）
この言葉は非常に道理にかなっているはずです。起業会社の友人によると、会社は Angular の使用を要求し、調査もなく、討論もなく、とにかく使用すると言います。なぜか？流行っているからです。適切かどうか、使いや���いかどうかは重要ではありません
自分の内部フレームワークはもちろん量体裁衣で、問題が発生すれば誰かが解決し、解決策を検索する必要がなく、使いにくければ自分で修正でき、修正が良ければ直接拡張でき、大きすぎれば整理して、あまり使用しない部分をオプションモジュールとして抽出できます。。。自分のものはもちろん他人のものより使い心地が良く、不満な箇所を修正できます。例えば $() の問題は、ビジネスシナリオに応じてよく選択し、document.querySelector がニーズを満たせるか確認し、ダメなら zepto の互換性が十分か確認し、本当にダメな場合のみ jQuery を使用します
五.なぜ MV* を理解する必要があるのか
更糟糕的是，今天无数经过演绎的 MVC 实现（如 backbone）和科普文，要么是原本作者概念已经很混乱，掺杂私货，要么为了适配现代的标记语言和控件模式，自己修改了经典 MVC 中的一些概念和耦合关系。实际上今天 MVC 已经没法作为一种交流的标准词汇了。
MV* を理解するために時間を費やすのは、他人が何を言っているのかを理解できるようにするためです。しかし上記の通り、MVC はすでに同業者間で瞬時に理解できる標準語彙ではなくなりました。正誤は重要でないかもしれません。もしこだわる必要があるなら N 篇の論文を読み、MV* の当初の実装理念を見つける必要があります。しかしその必要はありません。winter がすでに为我们に行ってくれたからです。当初の実装は 1 つの参照点で、他の MV* 実装に触れる際に対比して理解できますが、正誤にこだわらず、使いやすく実用的であればよいのです
コメントはまだありません