おれのIT日記
2005/12/16 (金)
Web Performerの紹介を聞く
今日はCanonソフトウェア社の無料紹介セミナーに参加させてもらってきた。
何だろう、これは単なる直感なのだが、DOAが復権している（のかどうか知らん、もしそうだとしたら。）のは、結局、RDBで実装するしかないので、O/Rマッピングで悩むより、最初からデータを意識しましょう、と、そーゆーことではないのかな。実際、現場のおれも、同じようなことをしているのであるが、だからと言って「DOAの復活」などと看板を掲げる気はこれっぽっちもないのである。オブジェクト指向ができなくても、DOAなら、みたいな言い方もちょっと気になった。これは、いわゆる「反動」なのか。気持ちもわかるし、全面的に否定もしないが、ちょっと、ヘンな方向に行く危険はないだろうか？
少なくとも、美しい設計と、実装上の問題をごちゃまぜにしそうな気がして、なんとなくイヤだ。なんとなくだ。
しつこいけど、おれも、過去の仕事で、同じアプローチを取ってきているから、言わんとすることは良くわかるつもりだ。
ちょっと話を広げよう。
例えば、SQL。あれは単なるチューニング対象としかおれには思えない。SQLでシステムを組むこと自体がなんというか、実装レベルのテクニック談義だと思うのだ。
だって、少なくともおれが相手しているお客さんは、自分でSQLなど組まない。だから、システム実装を、何でやるか、の選択肢に過ぎない。
そういう意味で考えると、Javaの内部データ表現が、そのまま、無限の拡張メモリに透過的に接続されて、永続化されるのが、一番理想的なデータベースなんだ。
そういう意味において、EJBは間違っていなかった。
ただ、ややこしすぎて、おれにもEJBはよくわからん。このややこしさは、システムの本質と違うところの、瑣末的なものだと直感できるので、避けてきた。
つまりEJBは思想において失敗したのではなく、実装において失敗したのである。（失敗と決め付けてスマン）
データベースを意識しないで済むフレームワークを作る。
すると、パフォーマンスが出ない場合が見つかる。そこでチューニングテクニックがもてはやされる。
パラメータを増やし、選択肢を増やす。フレームワークは肥大化する。
誰かがそれを批判して、また別のシステムフレームワークを考える。
……正に人類の業だよなぁ。
Spring Frameworkはちゃんと調べてないから論評は避けるとして、あの会場はどうしてあんなに寒かったのだろう。参った。風邪が悪化した。