DBFluteを今回採用した理由

周りからなぜS2JDBCではなくDBFluteを採用したのかと理由を聞かれるのですが、
それは以下のとおりです。


以下Seasar2 - S2JDBC-Gen - S2JDBC-Genとはより抜粋

S2JDBC-Genに適した開発スタイルとは、上記で説明したようにDDLの生成とマイグレーションを何度も繰り返すような開発スタイルです
(すでにデータベーススキーマが存在するときのみ、エンティティクラスをデータベーススキーマから生成します)。
エンティティクラスへの修正をデータベーススキーマに反映させるため、Javaコード中心の開発スタイルと言えます。
この開発スタイルでは、エンティティクラスや依存する他のクラスの修正を、EclipseなどのIDEリファクタリング機能を利用して
行えるというメリットがあります。

逆に、S2JDBC-Genに適さない開発スタイルとは、データベーススキーマの修正のたびにデータベーススキーマから
エンティティクラスを生成しなおす開発スタイルです。 これは、データベーススキーマ中心の開発スタイルと言えます。
この開発スタイルでは、データベースから自動生成する部分と、
手動で変更を加える部分を分離するGeneration Gapパターンの利用が一般的です。
しかし、S2JDBC-Genでは、データベースからのエンティティクラスの生成は最初の一度だけのみ行うことを想定しているため
Generation Gapパターンは採用していません。
S2JDBC-Genでは、直接修正しやすいシンプルなコードを生成します。
データベーススキーマ中心の開発スタイルを採用する場合は、S2JDBCS2JDBC-Genの組み合わせよりも、
DBFlute の利用を検討してみてはいかがでしょうか。

という訳で、今回仕様が確定しない状態のままプログラミングをしないと間に合わないため、
DBが変更するというのは必ずあると分かっていたためDBFluteを採用しました。

今回はDBFluteを採用して絶対に成功だと思ってます。
それが分かるのは1ヶ月後なのでまた後日結果を書きますが。

DBFluteの利便性に慣れてしまうと一生DBFluteを手放せないと思いますので、
まだ使った事無い人は一度使ってみてはいかがでしょうか。

ただ、これ以上DBFluteの機能が増えていくと未経験者が慣れるまでの勉強時間が増えるため、
そろそろどこかで方針を決めてくれてほしいですが・・・

特に関西のプロジェクトでは採用事例が少なすぎる。
俺も頑張るから関西のDBFluteユーザも頑張って広めましょう。