S2JDBCについてもう少し言っておくか
流れるようなので思考を中断せず云々みたいな事があるようだけどホントにそうかな？
気にしてるのは"where"とかってメソッドでこれってバリバリSQL意識してるからこの名前なんだろうなって気がする。
って考えるとここで言ってる思考ってのは実は「SQLを考える」ってなんじゃないか気がするのですよ。
whereの部分では、SQLをきっと考えるでしょう。でも、SimpleWhereを使えるような単純なやつは、手をとめずにそのままかける。
文字列でクライテリアを組むときも、書きたいSQLが頭の中にはあるはずだから手をとめずにすぐかける。
手を止めて考えなければいけないやつは、SQLファイルに書き出し、何度かSQLのコンソールから実行してみて、試行錯誤したほうがいい。そのような試行錯誤が必要なSQL文は、流れるように書くことはできないから、SQLファイルを使うのです。
わざわざ、SimpleWhereって実装クラス名にしているのは、難しいことはしないという意思が込められています。
sqlalchemyとか知ってるのか知らないのかわからないけどこれで足りうるか？って所が気になる。
意図的に若干足りないめに作ってあります。足りない部分は、SQLファイルを書けばいい。SQLファイルでもかけないような複雑で動的なSQLは、力技で文字列で組み立てて実行すればいい。
selectBySql()、updateBySql()、callBySql()はそのような意味で存在しています。
S2JDBCは、当初SlimDaoと呼ばれていました。Slimは、
をつなげたものです。「Less is More」こそ、S2JDBCの根底にあるコンセプトです。機能を肥大化させるつもりはありません。
Seasar Less is More
特に文字列系でスペルミスなんてうーんってなりやすい典型的な所だと思うのでそいつを防ぐ手立てがあった方が良かったように思える。
文字列で組み立てさせているのも意図的なものです。SimpleWhereで組み立てられないようなやつは、いろいろ機能を追加してがんばるより、文字列のほうがわかりやすいでしょうということです。
タイプセーフにもそれほどこだわってはいません。タイプセーフにするためにいろんなクラスを自動生成してがんばるより、さくっと文字列で書いて、スペルミスがあれば、わかりやすいエラーが出ればいいと思っているから。
小林さんのやつは、複雑になって開発者が手を止めないとかけなくなってしまうので、個人的にはあまり賛成ではありません。手を止めなくてもかけるくらいシンプルならいいんだけど。
http://d.hatena.ne.jp/koichik/20071026#1193396407
ちょっと複雑になってもタイプセーフのほうがいいという人はいると思うので、そういう機能は、DBFluteのように外から組み込めるようになっていればいいと思っています。
iPhone，ディズニーランド，スタバの共通点は？
にもでてくるように、高性能でなくても、機能が豊富でなくても、開発者に対する「おもてなし」ができればいいと思う。
どうすれば「おもてなし」ができるのかは難しいところだけど、簡単なところは、流れるようにコーディングができて、難しい部分は、フレームワークに振り回されることなく、ある程度力技で処理できることではないだろうか。そう思っています。
