JavaWebフレームワークは星の数ほどあります。それぞれ色々なスタイルがあって、それぞれ色々な場面に最適になるようにできています。「とりあえずこれはこうあって欲しい」というのがふんわり固まってきたのが...「事業会社だと、URLマッピングは規約ベースベースがいいなっ」って。自分もそう思ってるし、周りと話しても、わりとそう思っている人が多いです。元々は、Railsの発想から来ているはずです。SeaAction#land()URLからクラス名が決めるやり方。規約ベースの弱点の一つは、自由度が少ないこと。いざってときに、特殊なURLを表現することができない。Ymirはとても柔軟ですが、TeedaやSAStrutsはもろにそうでした。SAFluteでは、拡張で変更できるように。規約ベースの弱点は、クラス名やメソッド名が引きずられること。IndexActionだらけ、index.jspだらけ。ctrl+shift+Rしても、うへー(><。名前に変更できるように。その辺を回避できるようにしちゃいました。DBFlute規約ベースのうれしいとこは?すると、今度はメリット。URLとパッケージ・クラス構造が一緒になるということ。探しやすいctrl+shift+Rですぐに辿れる。画面をイメージしやすい。なんのドキュメントもなしに、なんの特別なツールもなしに、それができるってのうれしい。開発スタイルが違えば...「別に規約ベースでなくても、そんな大はずれなクラスにはしないでしょ?」と、普通は確かにその通り。最初からしっかりURLとそれに対応するクラス名も決めて、そしてそれが、途中でそんなに大変わりすることもあまりないかと思います。(あるときゃあるけど)マッピングのドキュメントもしっかりメンテされているでしょう。運営しながらそのビジネスを一緒に作り上げていくようなスピード重視のリーンスタートアップ・インクリメンタル開発、こういう現場だと、途中でどんどん大変わりしまくります。ドキュメントをキープしていくのは辛いです。成長の段階で新しいエンジニアが次々と参画していき、コーディング規約なんかも浸透しづらいものです。規則的でなければ、やっぱり探しにくいのです。「規約ベースのプロジェクト(SAFlute利用)」と「そうでないプロジェクト」のプログラムを行き来していますが...そのクラスやテンプレートファイルなどの探しやすさ、URL構造のわかりやすさが断然に違います。規模的には既にまるごと記憶できるレベルのものではありません。分析のスピードにも影響がでるなぁ、といつも感じています。HotDeploy、いつどこでだれと?既存コードの分析をする場面がとにかく多いその探しやすさとわかりやすさが活躍する場面が、じっくりの受注開発のときよりも圧倒的に多いでしょう。安心感あるなーというのが実感です。一理あるのかなって思ってしまいました。(HotDeployのこともあるしね)規約ベースをベースにで、もちろん特殊なURLを表現できないと苦戦するときもあるので、基本的に規約ベースなんだけど、いざとなったらカスタマイズできるっていうのが、ちょうどいいのかなって。「規約ベースベース」なのです。アプローチしていますが、ちょっとした工夫で、RequestMappingを空っぽにして、クラス名やメソッド名からURLを導出できるように...なーんてできないかなって模索中です。いうか、そういう機能あるのかも知れないけど...まだまだこれから(^^【追記】さっそく、makiさんからTwitterでコメント頂きました。なんとぅ、あるみたいです!やったー。再開したディズニーシーにはてなブログをはじめよう!jfluteさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。