DBFluteは、SQLファイルの解決を「自由」にしています。
要は「(クラスパス上の)フルパス」を指定します。
memberBhv.outsideSql()
.selectList("sql/member/selectXxx.sql", ...);
メリット：
A. Directory分けをアプリの都合良く設定できる。
B. SQLファイルの再利用がしやすい。
＜A＞
「テーブル毎の分けなのか、画面毎の分けなのか」
「テーブルのカテゴリ毎でディレクトリを分ける」
などなどアプリに適した形をアプリが自由に表現できます。
＜B＞
１つのファイルで２つの以上の実行を表現したい場合などに有効です。
ページング検索なんかはまさしくその恩恵に預かっています。
http://d.hatena.ne.jp/jflute/20071219/1198041971
S2Dao方式の場合はこれができなかったのです。
と、メリットを挙げましたがデメリットもあります。
デメリット：
SQLファイルのパスの解決にやり方に迷う。
DBFluteが昔採用していたS2Dao方式(今も動きます)と
対照的な特徴を持っています。
宣言的なやり方は、自由度が減りますが迷わない。
今既に、アプリ独自の規約でSQLファイルのパスの文字列解決を
されている方は特に問題ありません。そのままそのやり方でOKです。
ただ、DBFluteとしては、「自由」でもあり「宣言的」なメリットも
享受できるやり方を一つ提供したいと思います。
詳しくはまた。。。
それを外だしSQLの最終形仕様にしたいと思っております。
