FluxとMVC
以前、@mizchiさんのなぜ仮想DOMという概念が俺達の魂を震えさせるのかとか、id:saneyuki_sさんFluxアーキテクチャの覚え書きを書いたのを読んでて、いろいろ思うことがあったので纏めます。
Fluxは一方通行だから良い?
まず一つあるのが、この節です。
この資料は「そもそもMVCを誤解している」という批判も多いのですが、大事なのは「常に一方向にデータが流れる」という点にあります。
MVCも、もともと一方通行ですよ?
いや、まず言いたいのは、MVCも、もともと「一方通行」ですよっていうことなんですよね。
その前に、MVCについて誤解が無いように説明しますけど
- Smalltalkの設計指針などの、GUIを構築するためのMVC
- Webアプリケーションのサーバサイド処理をするためMVC
の2つがあります。ここでは、GUIのMVCについてです。
また、MVCとかMVVMとかありますが、そもそもMVVMって、マイクロソフトのWPFやらのためのアーキテクチャであって、あの強力な開発環境のサポートが無い、ブラウザでJavascriptでGUIを構築するようなものには向いてないんじゃないかと思うんですが、それはまた今度で。
んで、たとえば、http://www.cue.im.dendai.ac.jp/~masuda/mvc/index.html に、
依存を利用したMVC
(中略)
1.コントローラ1はモデルに変更メッセージを送る
2.モデルは自分自身に changed: メッセージを送る
3. dependency を通してすべてのビューに update: メッセージが送られる
4.各ビューがモデルに状態を尋ねて再描画する
とあり、そもそもMVCも一方通行なんですよね?
なんで、僕のとっては何の真新しさも無く、もにょもにょしていました。としていくと、するとFluxアーキテクチャの覚え書きを書いたこういった記述がありました。
一方通行のパターンに名前を付けただけ。
- ベストプラクティス的なパターンに名前をつけて共通言語としたところです。
- 概念的に非常に革新的な何かがあるというわけではありません。
- たぶん「誰もが一度は似たような事をやったことがある」と思うが、従来は個々人がそれぞれ別の言葉で呼んでおり、意思疎通の上で面倒くさかった
なるほどなー、と思いました。何も新しい概念で無いんだったら、変な名前付けんなと思うのですがね。
なんでシングルトンにするの?
StoreもDispatcherもシングルトンなサービスとして存在しているので（後述）、インスタンスの管理などの問題が軽減される
を見てて、いやいやなんか逆に、なんか密結合になったりするんじゃないかと思うんですが、なんでしょうかね?
そもそもGUIを作るのは大変だ
現時点での各種クライアントサイドMVC実装は、正直僕でも学習コストが高過ぎると思っているのですが、
たぶん、ここらへん、そもそもGUIってのが難しいと思うので、何やっても学習コストが高いか、学習コストが低いように見せかけて、そもそも問題を解決していないってこともあるとは思いますね。
なんで、FluxとかMVCとか、MVVMでやるべきとか、そんななんじゃなくて、たぶん、いろんあフレームワークやら言語やらをやって、自分なりに設計のベストプラクティスを作るべきなんじゃないですかね。