フロントエンドでMV*フレームワークを使わない理由
~
V = f( M.present( A(data) ) )
この式が規定しているのは、アクションが動くとき、アクションが入力されたデータセット(ユーザの入力など)を計算し、それがモデルが表現して、モデルが自分を更新する方法を決めます。更新が完了すると、ビューは新しいモデルの状態を描画します。これでリアクティブのループが閉じます。モデルの永続化とデータの検索はリアクティブなフローとは無関係で、絶対に、絶対に“フロントエンドエンジニアが書いてはなりません”。
アクションは純粋な関数で、状態も副作用もありません。
リアクティブMVCパターンは興味深いです。モデル以外はすべて純粋な関数だからです。Reduxはこのパターンを実装しているように思いますが、Reactの不要な作法があり、Reducer内のモデルとアクションの間に結合があります。モデルとアクションの間のインターフェースは純粋なメッセージパッシングです。 とはいえ、リアクティブMVCパターンはこのままでは不完全であり、Dan Abramovが言うように現実世界のアプリケーションは作れません。簡単な例で理由を説明します。 『MVCは、本当にあっというまに 複雑化してしまいます』と述べて、MVCはスケールしないと結論づけた。なにか新 しい機能を追加しようとするたびに、このシステムの複雑度は時々刻々と指 数関数的に増大し、そのコードは『壊れやすくて予測不能な』ものになって しまう。このことは、この種のコードベースに関わる開発者にとって新たに 深刻な問題を引き起こしている。なぜなら、なにか既存の機能を壊してしま わないかと彼らがコードに触れるのを恐れるからである。この結果、MVC は Facebookと決別することになったのである。 FacebookのソフトウェアエンジニアのJing Chen氏はさらに、MVCは小さなア プリケーションには適しているが、以下のスライドに示すようにモデルや関 連するビューが大量にシステムに加えられると複雑度が爆発してしまう、と 述べている。
https://scrapbox.io/files/645cf5650ba046001c7148e7.png
giveupitscrazy 氏：
これは、全く意味がないでしょうね。
まず１つには、彼らのMVCの構成には著しい欠陥があります。彼らは、コ ントローラが相互作用しているモデルに応じて分割するとか、なにか論理 的な分割理由があって、誰しもほぼ間違いなくコントローラを分割したく なるときでさえ、複数のモデルを操作するのにたった１つのコントローラ を使っています。 もちろん、彼らが説明しているような状況設定ならMVCは 動かないでしょうが、でもそれは そもそも本物の MVC ではないのです。
もし、彼らの Flux の構成図 と 本物のMVCの図を比較したなら、web アプリにとってMVCをが本質的に 悪い事などなにもないということが明確に理解できるでしょう。 koushisa.icon
依存関係が1:1でCRUDだけで完結するような極々小規模なアプリであればシンプルにコード量が少なく書ける アプリが管理するデータが少しでも複雑になったり子孫関係とかが現れると、組合わせ爆発を起こして破綻する 依存関係を制御するために
MV*や双方向バインディングはWhatとHowが密結合になるのでスケールしない