http://d.hatena.ne.jp/jflute/20080513/1210606397 でも書いていましたが、SQLのパスの解決として DBFluteは一つの仕組みを提供します。 その前に: 無論、今既に「自分たちのプロジェクト独自に規約を決めて解決している」 方々は上記に移行する必要は全くありません。今まで通りでしっかり動きます。 1. SQLファイルを作成 パッケージ:xxx.exbhv配下 ファイル名:[Behaviorクラス名]_[SQLを表現する任意の名前].sql 例えば、xxx.exbhv.MemberBhv_selectSimpleMember.sql 2. 2WaySQLを実装 いつものと変わらず 3. Sql2Entityの実行 MemberBhv.Path_selectSimpleMemberというstatic定義が自動生成される。 4. 外だしSQLの実行 String path = MemberBhv.Path_selectSimpleMember; ... memberBhv.outsideSql().selectList(path, ...); このように「とある特定のパッケージにとある規約通りのファイル名」を 配置してSql2Entityを実行すると、「タイプセーフ」なSQLのパス定義が できあがります。 これで得られるメリットは、 「SQLファイルありませんエラーが発生しない」 ことです。 後でファイルを変更しても、Sql2Entityをすればコンパイルエラーで 影響範囲がわかります。で、定義し直せばまた動く。 また、「SQLファイルの置き場所どうしよう?」と悩むこともありません。 SQLファイルの置き場所は「自由」にできる必要性はあるとは思います。 それは各プロジェクトでの都合に合わせられるように。 しかし、中規模クラスの案件では、ConditionBeanをしっかり使っていれば そんなに外だしSQLは増えません。そういう場合は自分たちで配置規約を 決めるより、フレームワークが提供する規約が合った方がうれしいことも あります。 さて、これだけでは、足りていません。 結局、規約に乗せると「不自由」というデメリットが発生するのが いやなのです。大規模案件でSQLが膨大の数になってきたときに、 一つのディレクトリに「ぐわー」っとSQLファイルが展開されるのは とてもいやです。このままでは上記のやり方は使えません。 exbhv配下にサブディレクトリを作成し、そこにSQLファイルを作成します。 そこでSql2Entityをやると、そのサブディレクトリのパスごとstatic定義を 生成します。 exbhv.category1.MemberBhv_selectSimpleMember.sql ↓ MemberBhv.PATH_category1_selectSimpleMember; そして、このまま実行するとサブディレクトリ配下のSQLが実行されます。 要は「SQLファイルのルートパッケージ」がexbhvなだけで、その配下に 自由に配置が可能です。規約と自由を両立させました。(かつ、タイプセーフ) そのサブディレクトリは任意のもので構いません。 会員系、購入系、商品系などとテーブルのカテゴリ分けが考えられます。 しかも、これは開発後半に「SQLファイルが多くなってきたなぁ」とかで、 サブディレクトリへのファイルの移動などを検討したくなった場合に、 「タイプセーフ」であることが大活躍します。 (DB変更時に再自動生成で影響範囲がコンパイルエラーで分かる というのと全く同じことです)