youseeの日記： DTOキライ

先日お客さん側の技術の人と話をしていたら、僕がDataTransferObjectは嫌いという噂がまことしやかに広まっていることがわかってちょっと驚いた。
「だってＸＸさん、DTO使わないでしょ」とか決めつけられて、……えっと、いったいナンノハナシデスカ？みたいな。

こういうことを言うと最近は年寄り扱いされるケースが多いんだけど、僕はRDBを使ったシステムを作るときはロジックを可能な限りSQLに書くようにしてる。なぜなら圧倒的に速いから。
でもプランナとにらめっこしていると、なぜか真空管でラジオを作っているのを見るような目で、見られてしまうのだ。

そんな彼らは文字列を切り貼りして、クエリのたびにSQL文字列を送りたがる人が多い。
prepareしないの？と聞くと「最近のサーバは速いから」とかそんな返事。べつにいいけどさー、電気代払うの俺じゃないし。と生暖かく見守っていると、得られた2つの結果をforループ（Javaとかの）で結合していたりして、さすがに僕もキレる。

なんでそんなことになっているのかと問い詰めると、DTOのクラス名と同じテーブルから列名と同名のフィールドに結果を自動的に云々、という話らしい。よくあることだが、オマジナイというか、伝統的なやり方で、それ以上の意味はない（誰も知らない）らしい。

結合結果を格納するものは彼らはDTOと呼ばないようで、つまり彼らにとってはDTOはテーブル構造を丸写ししたもののみを指す。もちろん、selectされる列は常に「*」なのだ。

僕は他社の伝統を壊したりしないし、オマジナイの種を仕込み直してあげるほどのお金ももらってないので基本的にスルー（支払いのよいところはもちろん別）。でも性能が必要そうな（システムの肝心な）部分だけは、その人たちの信じるDTOを使ったりはせずに自前で別のを書いたりするので、先に挙げたような噂が流れてしまったようだ。

いっぽう、僕の同僚君は、エクセルに書かれたDBの定義からテーブルに対応するDTOを生成するマクロを書いていた。
「どうせ納めたプログラムの行数でお金をもらえるんだからいいじゃない。うはうは」
すばらしい適応力。ていうか、俺って職業プログラマは向いてないんだなー。

最近の

[Anonymous Coward]

ORマッピングだ何だという開発方針では
彼らの方が正しいのでしょうし、(性能よりも生産性という志向←本当にそうなのかは微妙)
だからこそ、真空管ラジオを作れる人には
いざというときの需要が絶対あるはずです。

性能が出ないときに颯爽と現れて、がしがし解決
という立場ってのは、いろんな意味でお得だと思うんですよね。
誰でも出来る仕事は金にもならんし。