ひがやすを技術ブログ

電通国際情報サービスのプログラマ

S2JDBCが生産性10倍っていうけどさぁ

Seasar

何をもって10倍と言うのか、、、と思ったんだけど、

何に比べて生産性が10倍かというとJava標準のJPA(Java Persistence API)に対してです。

相手が悪い。
JPAと比べてどうするのって思う。

S2Daoと比較することで、S2DaoのユーザをS2JDBCに移行させることにどれほど意味があるのかは疑問です。それで、Seasar2のユーザが増えるわけではないから。
これまで、Seasar2のユーザではなかった人たちが、S2JDBCの生産性の高さに引かれて新規ユーザになってくれるのが望ましいシナリオではないでしょうか。
JPAはJavaの標準だし、比較対照としては妥当だと思います。標準だけど、生産性は高くない。一見簡単そうだけど、はまりどころが多くて結局生産性は悪くなる。だから、生産性を比較しやすいって「ずるい」計算もあります。

jdbcManager.callBySql("{? = call myproc(?, ?)}", dto).call();
さすがに、これはダメだろー。
生でストアド呼び出してるのと、変わんないじゃん。

生でストアド呼び出してるのと、変わらないからいいんですよ。何をやっているかが一目瞭然。そして、余分なJDBCまわりの処理はする必要がない。



jdbcManager.callProcedure("myproc", dto);
のように呼び出せたほうが、スマートに見えるかもしれないけど、そうするとデータベースメタデータを取りにいくか、規約を設けるかして、もとの"{? = call myproc(?, ?)}"を組み立てる必要がある。
データベースメタデータをとりにいくのは、パフォーマンスに問題がでるので、最近はS2Daoも取りに行かない方向に向かっています。規約は、一見便利だけど、間違えたときにどうしてもわかりづらくなる。
今回は、明確に「脱CoC」を打ち出しています。明示的に書くことで多少書く量が増えても、一目瞭然でトラブリにくいならそのほうがいいと思っています。

> 90%のSQLを自動生成する
自動生成と言っても、JavaでSQLを書くんでしょう？
私は、このJava式SQLが、いまだにダメで。
新人の時に、Hibernateで大失敗して以来、トラウマで（←自分が悪いｗ）

何でもJavaで書こうとすればきっとはまると思いますよ。でも、S2JDBCはそうじゃない。

  • from()
  • join()
  • where()
  • orderBy()
  • limit()
  • offset()

でかける範囲に限定して自動でSQLを生成し、それ以外は、明示的にSQLを書けというスタイルです。
上記の6つだけで構成されているなら、レビューはしやすいと思いますよ。

S2JDBCについてもう少し言っておくか

Seasar

流れるようなので思考を中断せず云々みたいな事があるようだけどホントにそうかな？
気にしてるのは"where"とかってメソッドでこれってバリバリSQL意識してるからこの名前なんだろうなって気がする。
って考えるとここで言ってる思考ってのは実は「SQLを考える」ってなんじゃないか気がするのですよ。

whereの部分では、SQLをきっと考えるでしょう。でも、SimpleWhereを使えるような単純なやつは、手をとめずにそのままかける。
文字列でクライテリアを組むときも、書きたいSQLが頭の中にはあるはずだから手をとめずにすぐかける。
手を止めて考えなければいけないやつは、SQLファイルに書き出し、何度かSQLのコンソールから実行してみて、試行錯誤したほうがいい。そのような試行錯誤が必要なSQL文は、流れるように書くことはできないから、SQLファイルを使うのです。
わざわざ、SimpleWhereって実装クラス名にしているのは、難しいことはしないという意思が込められています。

sqlalchemyとか知ってるのか知らないのかわからないけどこれで足りうるか？って所が気になる。

意図的に若干足りないめに作ってあります。足りない部分は、SQLファイルを書けばいい。SQLファイルでもかけないような複雑で動的なSQLは、力技で文字列で組み立てて実行すればいい。
selectBySql()、updateBySql()、callBySql()はそのような意味で存在しています。
S2JDBCは、当初SlimDaoと呼ばれていました。Slimは、



Seasar Less is More
をつなげたものです。「Less is More」こそ、S2JDBCの根底にあるコンセプトです。機能を肥大化させるつもりはありません。

特に文字列系でスペルミスなんてうーんってなりやすい典型的な所だと思うのでそいつを防ぐ手立てがあった方が良かったように思える。

文字列で組み立てさせているのも意図的なものです。SimpleWhereで組み立てられないようなやつは、いろいろ機能を追加してがんばるより、文字列のほうがわかりやすいでしょうということです。
タイプセーフにもそれほどこだわってはいません。タイプセーフにするためにいろんなクラスを自動生成してがんばるより、さくっと文字列で書いて、スペルミスがあれば、わかりやすいエラーが出ればいいと思っているから。
小林さんのやつは、複雑になって開発者が手を止めないとかけなくなってしまうので、個人的にはあまり賛成ではありません。手を止めなくてもかけるくらいシンプルならいいんだけど。
http://d.hatena.ne.jp/koichik/20071026#1193396407
ちょっと複雑になってもタイプセーフのほうがいいという人はいると思うので、そういう機能は、DBFluteのように外から組み込めるようになっていればいいと思っています。

iPhone，ディズニーランド，スタバの共通点は？

にもでてくるように、高性能でなくても、機能が豊富でなくても、開発者に対する「おもてなし」ができればいいと思う。
どうすれば「おもてなし」ができるのかは難しいところだけど、簡単なところは、流れるようにコーディングができて、難しい部分は、フレームワークに振り回されることなく、ある程度力技で処理できることではないだろうか。そう思っています。