大きいMVCと小さいMVC 語弊を恐れずに書く

MVCって、大抵の場合サーバサイドでの実装の分け方の事を言ってるのが多い気がする。んで、サーバサイドを作ってる人々の多くは、UIに関してはデザイナーがhogehogeとか、タンポポワークほげとか言ってる場合が多い気がするんだけど、実際どうなんだろう？

保存が必要なければ、ブラウザ内のJSだけでノートラフィック（初回DLは除く）でかなりのことが出来ると思うし、凝ったところはそうなっていると思う。MVCをサーバサイドとクライアントサイドで分けて考えると、実装者のリソースやら各データの祖結合具合だったりというのが上手に調整出来ると思うんだけどどうなんだろ？モデルにロジックてんこ盛り、否、コントローラも頑張るべきとか、いやいやテストすればモーマンタイでしょとかそう言うレベルじゃない気がする。

サーバーから動的に渡す部分はすべてJSONにして、それをサーバー側では最終アウトプット（View）にする、テンプレートエンジンのスピードとか関係なくなる。JSON素材をJSマスターがポコポコ配置していく、クライアントのCPU借りてレンダリングする。DLされる静的HTMLには、bodyタグとJS呼び出しだけが書いてある。それだけでいい気がする。

大きなMVC（サーバーサイド）と小さなMVC（ブラウザサイド）の連携で、サーバ実装者とJS実装者は、URLという発注書とJSONという納品書の会話だけで終わるすてきな世界にお互い住めると思う。アプリ作るのめんどくさいけど、ユーザからしてみればさくさく動くアプリで、変更要求も通りやすい（変更に対応しやすい）気がするんだけどどうなんだろう？（めんどくさいといいながら、対応しやすいっておかしいね）

セキュリティーの事は良くわからないので間抜けな事になってるかも知れないが・・・