リソース指向フレームワークのBEARが何やらスゴイ予感 - Stellaqua

これ、密かにスゴイぞ…。

「こんなWebアプリケーションフレームワークがあったらなぁ…。」と最近ぼんやりと考えていた、そのものズバリな感じで、かなり衝撃を受けています。今まで捕捉できてなかった自分に反省…。orz

今までRails以降の、いわゆるMVC フレームワークに何ともかんともなじめなかったんですが、このBEARに関しては、かなりすんなり考え方が入ってきました。

せっかくの機会なので、そもそも、なぜRails型のフレームワークが自分的にしっくりこなかったのか、ちょっと考えてみました。

まず、自分のイメージとしてRails型のフレームワークの場合、"URL1つに対してMVCの塊1つが対応する"という感じと思っています。

大雑把にいえば、動き的にはこんな感じですよね。

Railsの場合、このMVCの塊に対してCRUDのインターフェイスが与えられる訳で、REST的な考えで言うと、"MVCの塊1つ＝リソース"として見るとちょうどいいのかなと。

結果的に、1画面1リソースというのが基本になると思うので、1画面に色々な情報が詰まっているようなWebアプリケーションを作るのは難しいように思います。

ただ普通は、Webアプリケーションを作る場合は、1画面に色々な情報を表示する事も多いし、画面遷移が伴う場合も多い訳で、1画面1リソースという設計になる事は少ないですよね。

という辺りで、頭の中で思い描いているぼんやりとした設計が、直接MVCのフレームワークとうまく結び付かなくて、結局、ごにょごにょしないとうまく作れない事が多くて、「何だかなぁ…」と思ってしまっていました。

基本的な考え方として、"まずリソースありき"、つまり"ユーザに提供したいモノが何か?"という質問が最初に考えるべき問題だと考えます。

リソースが定義できた上で、それらをどのように表現するか・どのような画面遷移にするか、という事を考える…という流れだと、役割分担もすっきりして、きれいにWebアプリケーションを作れるのではないかと思います。

具体例として拙作の名付けて.ね〜むの場合、先に提供したい情報を洗い出して、"意味語"や"訳語"といったリソースを定義しました。

定義したリソースはRailsで実装して、そのリソースを読み込んだり登録したりするインターフェイスは、別途PHPで実装しました。

もちろん、Railsだけ・PHPだけでも作成できたとは思いますが、リソース層とWebアプリケーション層にきっちり分離できた事が重要だったと考えます。

が…わざわざRailsとPHPで別々に作っている訳で、やっぱり面倒だった事は否めません。(^^; それに、アクセスがある度にPHP側からわざわざHTTP通信で情報取得しにいくので、無駄が多いのも事実です。

今のところ、マニュアルをざっと読んでみただけではありますが、自分の理解だと、BEARはリソース層とWebアプリケーション層*1というような考え方の分離がなされているリソース指向のフレームワークで、かな〜り素敵な感じです。

現時点で理解したまでの知識で、ひじょ〜に大雑把に特徴を挙げると、以下のような感じです。

他にもおいしい機能いっぱいなんですが、自分的に一番コアなのは上記の辺りじゃないかと思います。

昨年1年は、"作ってみる年"と決めて、アイデアを出す練習と、アイデアから動くモノを作る練習として、"毎月1つWebサービスを作る"という目標を立てて実践してきました。

おかげさまで(?)、10個ほどのサービスが手元にあるので、まずはこれらをBEARに載せるという形でBEARを使ってみて、使い心地を試してみようかなと思います。使ってみた感想は、また追々…。

*1:この層の名前は自分的な勝手な名付けで、BEARのドキュメント内では出てこないのであしからず…。