Webフレームワークは星の数ほどあります。
それぞれ色々なスタイルがあって、
それぞれ色々な場面に最適になるようにできています。
しかしながら、ここ数年で、
「とりあえずこれはこうあって欲しい」
というのがふんわり固まってきたのが...
「事業会社だと、
URLマッピングは規約ベースベースがいいなっ」
って。
少なくともjfluteの身の回りでは、
自分もそう思ってるし、周りと話しても、
わりとそう思っている人が多いです。
規約ベースの弱点は?
Teeda や Ymir、そして、SAStruts がそうなってます。
元々は、Railsの発想から来ているはずです。
URLが "/sea/land/" だったら、
sea.LandAction#index() もしくは、SeaAction#land()
URLからクラス名が決めるやり方。
規約ベースの弱点の一つは、自由度が少ないこと。
いざってときに、特殊なURLを表現することができない。
Ymirはとても柔軟ですが、TeedaやSAStrutsはもろにそうでした。
SAFluteでは、拡張で変更できるように。
規約ベースの弱点は、クラス名やメソッド名が引きずられること。
IndexActionだらけ、index.jspだらけ。
ctrl+shift+Rしても、うへー(><。(特にSAStruts)
SAFluteでは、拡張で...
"/sea" だったら sea.SeaIndexAction とか、
sea_index.jsp とかの名前に変更できるように。
と、弱点はそれなりにあるわけなのですが、
最近よく使っている SAFlute では、
その辺を回避できるようにしちゃいました。
-> SAFluteトップページ | DBFlute
規約ベースのうれしいとこは?
すると、今度はメリット。
とにもかくにも、
URLとパッケージ・クラス構造が一緒になる
ということ。
これが担保されると何がうれしいかと言うと、
探しやすい
ctrl+shift+Rですぐに辿れる。
クラスを見た瞬間にURLと直結するので、
画面をイメージしやすい。
なんのドキュメントもなしに、
なんの特別なツールもなしに、
それができるってのうれしい。
開発スタイルが違えば...
「別に規約ベースでなくても、
そんな大はずれなクラスにはしないでしょ?」
と、普通は確かにその通り。
受注開発とかであれば、
最初からしっかりURLとそれに対応するクラス名も決めて、
そしてそれが、途中でそんなに大変わりすることもあまり
ないかと思います。(あるときゃあるけど)
マッピングのドキュメントもしっかりメンテされているでしょう。
だがしかし!
事業会社、特に、
社内にエンジニアを集めてビジネスサイドと近い場所で、
運営しながらそのビジネスを一緒に作り上げていくような
スピード重視のリーンスタートアップ・インクリメンタル開発、
こういう現場だと、途中でどんどん大変わりしまくります。
まず、ドキュメントをキープしていくのは辛いです。
成長の段階で新しいエンジニアが次々と参画していき、
コーディング規約なんかも浸透しづらいものです。
そんな中だと、
どうしても「えっ、このURLでこのクラス名!?」ってのも、
ちょっとずつ発生してきてしまうもので...
いやっ、そんなにひどいものでなくても、
規則的でなければ、やっぱり探しにくいのです。
# ちなみに、よくあるのが、
# クラスのURLパートとメソッドのURLパートの分割されてると...
# @Foo("sea")
# class Xxx {
# @Bar("land")
# public void yyy() { ... }
# }
# だと、"/sea/land" という文字列でgrepかけても
# ヒットしないという...(><
実際、行き来してると...
実際、jfluteは、
「規約ベースのプロジェクト(SAFlute利用)」
と
「そうでないプロジェクト」
のプログラムを行き来していますが...
そのクラスやテンプレートファイルなどの探しやすさ、
URL構造のわかりやすさが断然に違います。
規模的には既にまるごと記憶できるレベルのものではありません。
分析のスピードにも影響がでるなぁ、といつも感じています。
(厳密には、探すためのツールは用意されているのですが、
最新のEclipseだと動かないとかあったりして...
なんとか移行しようと...ちょい苦戦...(><)
そして、HotDeployのエントリでも書きましたが...
-> HotDeploy、いつどこでだれと?
既存コードの分析をする場面がとにかく多い
その探しやすさとわかりやすさが活躍する場面が、
じっくりの受注開発のときよりも圧倒的に多いでしょう。
(息を吸うかのごとく既存コードの分析はします)
なので、
放っておいても ※これ重要
クラスとURLが一致するフレームワークの方が、
安心感あるなーというのが実感です。
Railsがサービスの現場で多く使われてるってのも、
一理あるのかなって思ってしまいました。
(HotDeployのこともあるしね)
規約ベースをベースに
で、もちろん特殊なURLを表現できないと苦戦するときも
あるので、基本的に規約ベースなんだけど、
いざとなったらカスタマイズできるっていうのが、
ちょうどいいのかなって。
だから、
規約ベースではなく、
「規約ベースベース」なのです。
最近、ちょっとずつ SpringMVC にアプローチしていますが、
ちょっとした工夫で、RequestMappingを空っぽにして、
クラス名やメソッド名からURLを導出できるように...
なーんてできないかなって模索中です。
というか、そういう機能あるのかも知れないけど...
まだまだこれから(^^
【追記】
さっそく、makiさんからTwitterでコメント頂きました。
なんとぅ、あるみたいです!やったー。
-> 17.13.1 The Controller ControllerClassNameHandlerMapping
※いつもいつも、アドバイスありがとうございます(感謝感謝)