新しいものはすべて忘れ去られている

メアリー・エヴァンス・ピクチャー・ライブラリー/アラミー-エリス、R。1994。海の怪物。 ロバート・ヘイル株式会社



JavaScriptの世界のトレンドの玉座にある一連のフレームワークとライブラリは、もはやニュースではありません。 他の分野の開発者もこの点で私たちをからかいます。



そのため、作業の過程で、qooxdoo、jQuery、Ext JS、Backbone.js、Knockout.js、Ember.js、Angular、Reactなど、さまざまなライブラリとフレームワークを飛び越える必要がありました。



このフレームワークまたはそのフレームワークの選択は、必ずしも任意ではありません;アウトソースおよび人員配置モデルは、私の仕事に特定の制限を課します。 同じ地域の人が私を理解してくれると思います。



私が最後に決めたのは、FacebookのReactです。 私はそれを隠しません。同僚は、私がこのライブラリーに切り替えることに非常に消極的であったことを確認します。移行は快適ゾーンを離れることを意味します。 特に、FluxとReduxの人の建築スタイルの「新しい」再考、「新しい」用語-アクション、ストア、ディスパッチャーなど、多くの新しい言葉が怖かったです。



同意して、以前のすべての「ハンマーと釘」では、辞書は通常、 Model-View- * （Controller || Presenter || Adapter || ViewModel || Whatever）のようなものになりました。



この辞書の私の理解は、この写真のように見えました。









これは、かなり人気のあるUdacity MOOCプラットフォームの「JavaScript Design Patterns」コースの写真です



私はこの写真が好きでした。 そのため、多数のクローンとMVCのさまざまな解釈が存在する世界を簡単に認識できました。



ビューがあります-これはhtml、css、およびそれらすべてです。 モデルがあります-これはJSONデータであり、それを取得した場所です。 そして、クラーケン/タコ/ヤスデ/ムノゴルカ-データとビューを組み合わせた一種の神話上の生き物です。



MVOはすべての質問に対する答えです。









そして突然Facebookがやって来て、MVCが悪いと言って 、それと混同し、依存関係のこのネットワークから抜け出すことができません：









そして、彼は銀の弾丸があると言います- フラックスと単方向データフロー ：









それから他の誰かが来て、Fluxは複雑だと言います、Reduxはあなたが必要なものです。

Facebookであるため、これらの人たちは多くのことを知っているので、あなたは信じる傾向があります。



現在、すべてがこのアーキテクチャスタイルとライブラリによって決定されています。 フロントエンドが必要ですか？ わかりました、React、Redux、およびサンク、サガ、ストーリーブック、themr、flow、およびhatの形でさらにいくつかの荷物を取ります。



いいえ、Reactは素晴らしいライブラリだとは思いません。 Virtual DOMテクノロジーにとても満足しています。これは非常に重要なタスクを本当に解決します。 リアクティブプログラミングパラダイムにリンクすることも、私を幸せにします。 しかし、ここに「新しい」建築様式があります...



私たちの業界は急速に発展しています-それは良いことです。 2017年には、1980年に比べて数百倍のプログラマーがいます-これも良いことです。 多くのクールなツールは、アプリケーションプログラマの生活を楽にするように見えます-これも間違いなく良いことです。 しかし、アプリケーションプログラマである私たちは考えることを減らし始めています。 少なくともそう思う。 プロのプログラマーとしての5年間の仕事で、私は平凡で紛らわしいコードをたくさん書きました。



しばらくの間、私はやめることにしました。 Facebookのようにさらに先に進む前に、Webアプリケーション開発を再考する必要があります。 Unidirectional DataflowがこのWebの問題を解決する理由、Facebookの前に誰もそれをしなかった理由、MVCがあらゆる方向の矢印でそれほど悪い理由を理解してください。



そして、私は逆の順序で始めました。

MVC

他のトップ開発会社がこのアーキテクチャスタイルの定義を提供しているものを見て始めました。 実際、ほとんどの場合、私たちはこれを行い、有能な人、体重のある人に会いに行きます。



Facebookからの解釈に慣れました。









以下は、Microsoftの解釈です。









モデルとビューは反対方向に接続されていませんが、説明から明らかなように、モデルはビューからの状態要求に応答する必要があります。



つまり 一般的に、解釈はFacebookの解釈と同じです。



私たちはアップルに行きます、これらの人は2つの完全なスキーマを持っています（伝統的なバージョンとCocoa APIのバージョン）















うーん、面白い。 最初のオプションはわかりにくいようです。 ここでは、以前の解釈のように、モデルは両方向の表現と接続されています。 ただし、コントローラーとの通信は一方向ではありません。 ユーザーのアクションは、ビューを介してコントローラーに送られます。



2番目のバージョンでは、モデルと表現は直接関連しなくなりました。 インタラクションはコントローラーを通過し、タコの絵のように見えます。



そしてここにGoogleがあります









まあ、あなたはすべて同じクラーケンを理解しています。









以下は、Martin Fowlerのブログからの概略図です（ところで、彼はGUIアーキテクチャに関する非常に興味深いシリーズの記事があり、MVCの解釈について詳しく説明しています）。









以下は、Javaなどの近隣世界からのMVCの解釈です。 JSPを直接知っています。 暗い過去、いわば。









まだ混乱していませんか？ シリーズのXファイルの様子を覚えていますか？ 真実は近くのどこかにあります。



1つのことは明らかです。すべてのオプションは似ており、それらはすべてほぼ同じですが、Model-View-Controllerの解釈には定説がありません。 なぜそう どうやら、元の文言がそれほど厳密ではなかったためです。 それとも多分それは？



多くの場合、技術を非常に表面的に判断します。 私たちは、元の情報源を開き、私たち自身の意見を形成する代わりに、信仰に関する他の人々の解釈を受け入れます。



MVCの主なソースは何ですか？

1970-80年代

ボブおじさんが彼のセミナーで尋ねたのと同じ質問で記事を始める価値があると思います。



これが誰か知っていますか？









これは、この建築スタイルを最初に説明したMVCのまさに創始者であるオスロ大学の教授であるTrygve Reenskaugです。 これは、1978年にゼロックスPARCのLearning Research Groupを訪れたときに起こり、現代タブレットの類似物であるDynabookプロジェクトの基礎として、この概念の基礎が築かれました。



彼は次の引用でクレジットされています：

MVCは、大規模でわかりにくいデータセットを制御するというユーザーの問題に対する主な解決策として考えられていました。 最も難しかったのは、さまざまなアーキテクチャコンポーネントの名前です。 （注Wikipedia）

どういうわけか、この声明はFacebookの写真に反しています。



クリエイター自身がこの建築スタイルをどのように描いているのかと思っていました。 そして、その時代の興味深いスキームがいくつかあります：





















面白い写真ですね。 私がそれらについて一番気に入っているのは、ユーザーの外観です。 これは、クライアントソフトウェアのアーキテクチャを記述するスキームにとって重要であるように思えます。



2番目の興味深い点は、初期のサーキットでのコントローラーとプレゼンテーションの統合領域です。 TrygweはこれをEditorとして定義し、後でToolとして定義します。



この概念に関する彼の最初のメモでは、モデル、ビュー、コントローラー、エディターという4つの用語が定義されました。 エディターは、プレゼンテーションと、マウスやキーボードなどの入力デバイスとの間のインターフェイスとして、プレゼンテーションがオンデマンドで作成する一時的なコンポーネントです。



TrygveがXerox PARCを離れた後、Jim Altoffと他の人々はSmalltalk-80クラスライブラリのMVCの最初のバージョンを実装および実装しました。 教授はこの仕事に関与していませんでした。



ジム・アルトフ教授によると、「コントローラー」という用語の解釈は多少異なります。



元のMVCの重要な側面は、そのコントローラーがその従属ビューの作成と調整を担当することでした。



後の注で、ビューはそれ自体に関連するユーザー入力を受け入れて処理します。 コントローラーは、コントローラー/ビューアセンブリ全体に関連する入力を受け取り、処理します。これは現在、 ツールと呼ばれています。



ところで、Martin Fowlerはこのタンデムプレゼンテーションレイヤーを呼び出します。



Trygveは、クライアントシステムの主要なプレーヤーはエンドユーザー（ メンタルモデル ）とドメインデータ（ ドメインモデル/データ ）であると指摘しています。 また、MVCの主な目標は、ユーザーのメンタルモデルとコンピューターに存在するデジタルモデルとの間のギャップを埋めることです。



この概念は、SmallTalkの時代であり、Webアプリケーションの概念がそのように存在しなかったという事実にもかかわらず、今日に関連しています。 ユーザーとデータの相互作用は、プログラムの本質です。 これらのオブジェクトの間には、相互に通信するためのレイヤーがあります。









プログラムと人の相互作用の基礎は、常に入力および出力データストリームです。 一般化されたスキームは次のようになります。









したがって、コントローラーをデータエントリポイントとして解釈し、ビューを出口ポイントとして解釈します。 エントリポイントとは、周辺機器とプレゼンテーションコントロールの組み合わせです。 同時に、ビューとコントローラーは暗黙的に接続されますが、直接通信しません。 プレゼンテーション。ユーザーアクションに関するメッセージをコントローラーに送信する義務を委任したかのように。



入力ストリームはサブジェクトモデルの状態を変更できますが、モデルはデータ出力ポイントを使用してユーザーにその変更を通知する必要があります。









Trygveの回路の1つでは、コントローラーとプレゼンテーションの接続は1対多です。 なんで？ 当時は、ユーザーインターフェイス上のボタンや矢印がビューだったからだと思います。 それ以降、何か変更はありましたか？ 私はそうは思いません。



クラーケンの解釈では、ビューはページ全体を意味すると理解されることがよくあります。 実際、それは常にコンポーネントのツリーです。 各コンポーネントは、表現として機能する可能性があります。











ユーザーインタラクションレイヤーと多対多モデルの関係。 これは現在のプログラムに当てはまります。1つのページにさまざまなサブジェクトモデルのデータと特性を表示できます。一方、モデルはデータ構造にできます









MVCの一般化された説明を定式化してみましょう。

• モデル（ Model ）はデータを提供し、コントローラーコマンドに応答してその状態を変更します。
• ビューは、モデルデータをユーザーに表示し、モデルの変更に応答します。
• コントローラーはユーザーのアクションを解釈し、変更の必要性をモデルに通知します

いくつかの直接的な単方向データフローが出てきます：









ウィキペディアからの画像







しかし、これはFacebookとCoが提供するものと同じではないでしょうか？

• ストレージ（ Store ）-データストレージ。
• Dispatcher-ユーザーアクションをリポジトリに送信します。
• Representation（ View ）-React-componentsのツリー。
• アクション -ユーザーのアクション、平面オブジェクト。
• Action Creator-アクション（オブジェクト）を作成します。
• Reducer（ Reducer ）-データウェアハウスの状態を変更します。

革命は起こらなかったことがわかります。 何も変わっていません。 すべては、MVCのプリズムを通過しています。 この概念の次の解釈と概念の置換のみを観察します。



そして、Facebookの代表者はそのときどのような問題について話していましたか？



おそらく、時間の経過とともに、システムの職務分離の概念の解釈が特定のテンプレートの実装に削減されているという事実から始める必要があります。



Appleの図をご覧ください。 それらは特定のパターンでシステムのレイヤーを記述します：リスナー、戦略、構成。 この誤りは、「 ギャングオブフォー 」の登場以来続いています。



サーバーとクライアントでのコンソールソフトウェアの進化により、初期の定義にその痕跡が追加されました。



抽象化は具体的なものに変わりました。









問題に関しては、問題はまだ同じであり、長い間表明されてきました。 Flux / Reduxでも同じです。 そして、他のコンセプトとフレームワークのために。 最初は、純粋な思考を持ち、シンプルなものから始めます。 しかし、時間の経過とともに、コードの思考の純粋さを維持しなくなると、ひどいクラーケンパスタモンスターに変わります。 プロジェクトはこのタールピットで立ち往生し始めます。















ReduxとFluxは、プロジェクトのアーキテクチャをよりクリーンで理解しやすいものにするのに役立ちますか？ 彼らはこの純粋な考えを維持しますか？ これらの矢印のボールにスライドできないツールはありますか？



ツールおよび定期的な解釈として、彼らには生命権があります。 しかし、現在のプロジェクトでは、Reduxを徐々に削減し始めました。 これが何をもたらすのか見てみましょう。 この純粋な思考を維持することは可能でしょうか、それとも再び沼地になりますか。

結論

人間とコンピューターの相互作用の分野で根本的な変化が起こるまで、全体の概念は常にこれに基づいています。









すべてがこの観点を通過します。 そして、さまざまな方向のこれらの数百の矢印の問題は、この概念でさらに生き続けます。



誰かが何とかきれいに書くことができただけなのに、誰かがまだ自分の沼地で立ち往生しています。

そして、この概念の端はこの沼のソースコードで消去されます。 私は経験から知っています、彼自身が多くのプロジェクトをこの泥沼に変えたからです。



あなたはおそらく質問をしたいでしょう：「 まあ、クールな男、そして次は何ですか？ 」

何も、このテキストを私の脳のダンプとして扱いません。



これで、これらの用語に没頭できたことをうれしく思います。これは、Webアプリケーションのクライアントレイヤーの開発の「再考」です。 少なくとも私にとっては、MVCを新しい方法で解釈し始めました。 これらの用語のより抽象的な解釈。



また、自分の考えを発表する機が熟したことを嬉しく思います。 おそらく、しばらくすると私の意見が変わり、このテキストに戻って笑うのは面白いでしょう。



PS上記のすべては、私の謙虚な主観的な意見と私の解釈です。 そして、あなたとはどうですか？ artur.basak.devingrodno@gmail.comの他の視点を見て喜んでいます



記事の続き

->「クラーケンの謎」-MVCなどの歴史について簡単に説明します 。

->「クラーケンハンティング」-フラックスは複雑で、Reduxはロールバックせず、すべてをArtuxに単純化します

参照資料

→ MVC Wiki

→ Trygver MVC

→ フラックス

→ Apple MVC（1）

→ Apple MVC（2）

→ Google MVC

→ ボブおじさん

→ マーティンファウラーMVC