Entries

スポンサーサイト

カテゴリ:スポンサー広告
更新日:--------
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

backbone.jsを選んだ理由 - Ajaxのためのアーキテクチャを目指して

カテゴリ:backbone.js
タグ: backbone.js  ajax  MVC 
更新日:2012-12-30
何故か見落としてたんだけど、backbone.jsを選んだきっかけになった記事は、これだった。

> そろそろBackbone.jsでの開発について一言いっておくか(・ω<) - tsundere note(・ω<)

「サーバサイド、フロントの分業の確立」とか、「API仕様書を用意せよ」とか。Ajaxで開発している時に考えているアーキテクチャに近いと思った。これなら、今の作り方をそんなに変えなくても使えるんじゃないかと思ったんだよね。

で、今考えている、Ajaxのためのアーキテクチャをちょっと整理しておこうと思う。

backbone.jsは、JavaScriptのMVCフレームワークとして紹介されるんだけど、サーバーサイドのMVCとは、ちょと違うよ、という話がある。

> Backbone.js入門 「MVC」 - Qiita

サーバーのMVCってのは、よく知らんのだけど、いつの頃からかWebアプリでMVCって言われた頃から、なんか違和感があるんだよね。

サーバーのMVCにも、いろいろ解釈の混乱があるようなんだけど、ほぼControllerの理解に起因しているようだ。上記の記事では「 View が Controller の機能も含んでいる」と考えればMVCだという。Wikipediaによれば、このようなVCが分離されていないものを拡張MVCと呼ぶらしい。

> Model View Controller (Wikipedia)

UIにおける入力と出力は本質的には不可分なものであり、したがってviewとcontrollerはいつでも分離できるとは限らない。このようなM-VCとなるような構造を拡張MVCと呼ぶことがある。


Controllerって、ユーザーの入力を処理する部分と考えているわけで、そもそもGUIになった時点で、Viewに隠蔽されてしまう。これについては、以前書いた。

> [Delphi for PHP] DelphiとMVC - fintopo

サーバーサイドでは、httpでのアクセスがユーザー入力と考えるんだろうけど、それってほんとにユーザー入力なんだろうか?

> RESTって、何か好きじゃない - UpdateとCreateは分けないといけないのか? - fintopo

ブラウザでハイパーリンクを辿る、と考えれば、ユーザー入力と言えるかもしれない。RESTは、そういう考え方に基づいている。RESTfullってのは、サーバーとRESTなやり取りを繰り返すことでアプリケーションを実現する。これは、ハイパーリンクだけでアプリケーションになるってことだけれど、一方で、画面遷移が前提になる。

> AjaxとRESTのパラドックスからWeb2.0を考える - Randomwalk(ITmedia オルタナティブ・ブログ)

けど、時代は、Ajaxを選んだ。画面遷移は、作りやすさの反面、UXは良くないのだよね。

RESTは、対SOAPとしては、意味はあったと思う。Web APIとして、SOAPほどの複雑さはいらないよね、ということだ。だけど、Ajaxになってくると、RESTfullであることは、逆に枷になってきているように思う。RESTfullは、Ajaxのアーキテクチャとしては、不十分なんだと思う。

では、どうするか?まぁ、拡張MVCという考え方をしてもいいし、MVCにさらに要素を追加してもいいかもしれない。だけど、そういう修正をしないといけない時点で、MVCというモデルは、もうあんまりあてになってないようにも思う。

もっと素直に、三層構造で考えればいいんじゃないだろうか?

> 多層アーキテクチャ - Wikipedia

よく、MVCと三層構造の混乱も見られるけど、もちろん、これは違う概念だ。Webアプリの場合、ブラウザ(プレゼンテーション層)、サーバープログラム(アプリケーション層)、データベース(データ層)の区別が明確につく。そして、Ajaxによって、クライアントサイドの開発が重要になってきた。

ならば、言語的にも独立しているわけで、これを一体化したフレームワークで開発するよりは、それぞれの層で独立した開発をしたほうがいいんじゃないかと思う。

JavaScriptでは、表示とユーザーの操作に集中する。確かに、APIで取ってきたデータを管理する必要はあるからコピーとしてのモデルは必要になるけど、基本はビジネスロジックを含めてサーバーサイドで管理され、WebAPIが切り口になる。

このアーキテクチャで作ってみると、サーバー側は、ほんとうにシンプルなんだよね。ほとんどは、WebAPIとデータベースとのやり取りをするだけ。入力-処理-出力という単純な流れで、COBOLの教科書みたい。件の記事では、「Pのつく言語を卒業する理由づけの一つにできるだろう」とあるけど、あまりにシンプルすぎて、Pのつく言語じゃダメな理由も殆ど無い。こだわることがあほなくらい、なんでもいい、って感じになる。

MVCで考えるならば、モデルが三層にわたって展開されていることになる。だから、それぞれの特徴を生かした処理の分割を考える必要が出てくる。データ層もRDB一辺倒からNoSQLという動きが出ているのはデータの分散を考えた時に、そのほうが有利だからだ。処理が単純だからといって、RESTfullにしちゃって、二層構造にしちゃってはもったいないのだ。

サーバーサイドで考えることは、いくらでもある。アプリケーション層とプレゼンテーション層で、どのように処理を分散したらいいのか?データ層には、何をどうやって保存したらいいのか?端末の性能やサーバーのインフラを考慮して全体の効率を考えれば、同じ処理をするのにしても、サーバーサイドですべて処理する「重い」APIだけでなく、クライアントサイドで複数のAPIで実現する「軽い」APIがあってもいいかもしれない。

そうして、データ処理を意識しなくても良くなれば、プレゼンテーション層の開発は、UXを高めるためのUIの開発に集中できることになる。

実際にbackbone.jsを試してみて、今まではJavaScriptの技術不足でイメージはあるんだけど、どう書いたらいいのかよく分からなかった部分が、補足されるのが分かった。なんか、ほんとにしっくり来る感じ。早く仕事で使えるようにしていきたいなぁ、と思っている。
スポンサーサイト

Appendix

プロフィール

いむら@fintopo いむら@fintopo

ガーデニングが趣味のフリーのシステムエンジニア兼プログラマ(フルスタックエンジニア)です。

仕事募集中です。個人なので、融通がききます。 大規模な開発はできないかもしれませんが、研究や製品開発レベルでの小規模開発、特に相談しながら新しいものを作っていくのが得意です。詳しくはWebサイトをご覧ください。
詳しくは「fintopoとは」をご覧ください。

> fintopoとは

このページのQRコード

季節暦

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。