フロントえんじゃないか

Ruby on rails だっけな？　ま、それは方法論。　手段だからいいんだけどさ。

アーキテクチャ（設計思想）ってものを理解してないといけない。

ずっと前にやったのはMVCモデルというものだった。

イメージ図だけは持ってこようか。(｀-д-´)y-~~

まぁ、いい図かどうかわからないけど、M,V,C というオブジェクトの役割が見てとれる。

こういう概念、観点が抜けていると、ただの一見似たようなソースの$\mathfrak{B}$集合族になっちゃうわけだよ。

・イベントのハンドリングがおかしい！щ（°д°щ）

・見せ方変えたい。( ･ω･`)

・DB切り替えたし！(　･`ω･´)

てな要望や修正は、それぞれ誰（担当）に頼むの？ってことと同じハズだ。

たとえば、View を担当するのはデザイナーさんがふさわしいだろう。

コールバック関数って何？なんてことでも、たとえばデータを一生懸命探したり監視してる人（M）が作業終わったときに、V さんに知らして欲しいとかあるよね。

だから、関数（処理）が終わったときに、私の（登録、提供）関数呼び出してねっていうものなんすよ。

M さんは、その中身なんて全然わからなくてもエエの。

で、この図は、実はいささか不透明なところがある。

ユーザーとデータのやりとりしているホストが、クライアントなのかサーバなのかわからん。

それはどっちでもいいんじゃね？ってことなんすよ！( °Д°)ｸﾜｯ

いや、むしろユーザーの滞在時間が長いとか、サーバに負荷の掛かるような構成だったら。。

そりゃあ、なるたけクライアントの方でやってもらいたいよね～。♪～ <(ﾟεﾟ)>

で、MVCってのをやったのはもうずいぶん前のことだ。

この構成の欠点は C さんの負担が重いこと！

ユーザーからの要求を常時受け付けなければならないのはもちろん、任せた仕事の結果は知らんてなわけにもイカンよねｗ

それで１対多というのは想像以上にキツいのである。

そこで登場したのが MVVM モデル！( °Д°)ｸﾜｯ

C さん何処逝った？(・ω・；)ｷｮﾛｷｮﾛ(；・ω・)

これは VM というサーバサイドの資源を クライアントにバインドしちゃえばいいじゃん( ･ω･`)

てなこととなっ！( °Д°)ｸﾜｯ

関数型言語なんかでもありましたね～バインド。（ ￣-￣）

ここ任せろ下さい。　って言われましてもな。（＾＾；

（vue.js 公式ガイドより）

結局、ライブラリの中身はともかく内容を知らんとな。

要は大抵 M さんが保持ってるものを V さんがバインディングして表示すりゃええだけじゃねと。

ま、万能じゃないんで、あくまで使いどころ次第ってことにはなりますか。。

こんなこともあるようで。

ひとつの目立たぬ大きなトレンドになることは間違いない。　のか？