Hatena::ブログ(Diary)

yvsu pron. yas このページをアンテナに追加 RSSフィード

2007-10-26

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

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

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

相手が悪い。

JPAと比べてどうするのって思う。

2007-10-25 - せろ部屋?

S2Daoと比較することで、S2DaoユーザS2JDBCに移行させることにどれほど意味があるのかは疑問です。それで、Seasar2ユーザが増えるわけではないから。

これまで、Seasar2ユーザではなかった人たちが、S2JDBC生産性の高さに引かれて新規ユーザになってくれるのが望ましいシナリオではないでしょうか。

JPAJavaの標準だし、比較対照としては妥当だと思います。標準だけど、生産性は高くない。一見簡単そうだけど、はまりどころが多くて結局生産性は悪くなる。だから、生産性を比較しやすいって「ずるい」計算もあります。

jdbcManager.callBySql("{? = call myproc(?, ?)}", dto).call();

さすがに、これはダメだろー。

生でストアド呼び出してるのと、変わんないじゃん。

2007-10-25 - せろ部屋?

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

jdbcManager.callProcedure("myproc", dto);

のように呼び出せたほうが、スマートに見えるかもしれないけど、そうするとデータベースメタデータを取りにいくか、規約を設けるかして、もとの"{? = call myproc(?, ?)}"を組み立てる必要がある。

データベースメタデータをとりにいくのは、パフォーマンスに問題がでるので、最近S2Daoも取りに行かない方向に向かっています。規約は、一見便利だけど、間違えたときにどうしてもわかりづらくなる。

今回は、明確に「脱CoC」を打ち出しています。明示的に書くことで多少書く量が増えても、一目瞭然でトラブリにくいならそのほうがいいと思っています。

> 90%のSQL自動生成する

自動生成と言っても、JavaSQLを書くんでしょう?

私は、このJavaSQLが、いまだにダメで。

新人の時に、Hibernateで大失敗して以来、トラウマで(←自分が悪いw)

2007-10-25 - せろ部屋?

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

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

でかける範囲に限定して自動SQLを生成し、それ以外は、明示的にSQLを書けというスタイルです。

上記の6つだけで構成されているなら、レビューはしやすいと思いますよ。

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

流れるようなので思考を中断せず云々みたいな事があるようだけどホントにそうかな?

気にしてるのは"where"とかってメソッドでこれってバリバリSQL意識してるからこの名前なんだろうなって気がする。

って考えるとここで言ってる思考ってのは実は「SQLを考える」ってなんじゃないか気がするのですよ。

S2JDBCについてもう少し言っておくか - 回転と脱線

whereの部分では、SQLをきっと考えるでしょう。でも、SimpleWhereを使えるような単純なやつは、手をとめずにそのままかける。

文字列でクライテリアを組むときも、書きたいSQLが頭の中にはあるはずだから手をとめずにすぐかける。

手を止めて考えなければいけないやつは、SQLファイルに書き出し、何度かSQLのコンソールから実行してみて、試行錯誤したほうがいい。そのような試行錯誤が必要なSQL文は、流れるように書くことはできないから、SQLファイルを使うのです。

わざわざ、SimpleWhereって実装クラス名にしているのは、難しいことはしないという意思が込められています。

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

S2JDBCについてもう少し言っておくか - 回転と脱線

意図的に若干足りないめに作ってあります。足りない部分は、SQLファイルを書けばいい。SQLファイルでもかけないような複雑で動的なSQLは、力技で文字列で組み立てて実行すればいい。

selectBySql()、updateBySql()、callBySql()はそのような意味存在しています。

S2JDBCは、当初SlimDaoと呼ばれていました。Slimは、

Seasar Less is More

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

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

S2JDBCについてもう少し言っておくか - 回転と脱線

文字列で組み立てさせているのも意図的なものです。SimpleWhereで組み立てられないようなやつは、いろいろ機能を追加してがんばるより、文字列のほうがわかりやすいでしょうということです。

タイプセーフにもそれほどこだわってはいません。タイプセーフにするためにいろんなクラス自動生成してがんばるより、さくっと文字列で書いて、スペルミスがあれば、わかりやすいエラーが出ればいいと思っているから。

小林さんのやつは、複雑になって開発者が手を止めないとかけなくなってしまうので、個人的にはあまり賛成ではありません。手を止めなくてもかけるくらいシンプルならいいんだけど。

http://d.hatena.ne.jp/koichik/20071026#1193396407

ちょっと複雑になってもタイプセーフのほうがいいという人はいると思うので、そういう機能は、DBFluteのように外から組み込めるようになっていればいいと思っています。

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

【IPCM】iPhone,ディズニーランド,スタバの共通点は?──人気ブログ「Life is beautiful」の中島氏が講演:ITpro

にもでてくるように、高性能でなくても、機能が豊富でなくても、開発者に対する「おもてなし」ができればいいと思う。

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

koichikkoichik 2007/10/26 23:00 or() と and(Where) はともかく,EntityCondition は手が止まることはないんじゃないかな.サクサクと補完してもらえるので文字列よりラクチンですよ.EmployeeCondition とかが出来てることが前提になるけど,エンティティとセットで作ればいいだけだし.SimpleWhere とも完全に独立してます.

higayasuohigayasuo 2007/10/26 23:24 EntityConditionは、誤解してたかも。
andでつなげるだけなら、SimpleWhereよりも、補完が効く分、さらに流れるようにコーディングできそう。

ykkykk 2007/10/27 02:34 結局のところS2JDBCとS2Daoどっちが生産性がいいのですか?

Connection: close