サーバプラットホームが全てを決める(DTOとDAO)

私は自分のエントリが言及されたり、コメントされた場合にはできるだけ"すぐ"に反応するようにしている。出不精な私でもプロの開発者とコミュニケーションできる機会だからだ。

DTOとDAO - Mimori's Algorithms tDiary

それなのに、すぐ反応しないで申し訳ない。丁度、はてなアンテナがおかしかった時だったからかな、と言い訳してみる。

バックエンドがSQL Server という前提で開発している現時点では思いっきり DataSet ラヴ! である。
- DTOとDAO - Mimori's Algorithms tDiary

Webアプリケーションが主体になった今でも、システム開発の方向性を決める一番の要因の一つは、バックエンドプラットホーム(DBサーバ含む)が決まることだろう。バックエンドが固定されている環境ではDTOやDAOをどうやって用意するか、などを論じることなどすっ飛んでしまうことがある。仮にサーバ、それもDBサーバがSQL Server(& WindowsServer)なのであれば、私もDataSet(DataTable)を多用することだろう。なんといってもサポートが違うし、リモート処理を考えると直接サーバとの間でシリアライズ/デシリアライズできるってのはSOAPを無視しているとしても、強力だ。ADO.NET2.0からは1.1では使えなかった、真のバイナリフォーマッタが使えるようになり、消費される通信帯域が劇的に少なくなったのも魅力だ。

私がDTOはPONOで、DAOは用途でと書いたのは、特定のサーバプラットホームを前提にしていない。ぼんやりと見えているのはJavaプラットホームが動作する不特定のサーバで、DBサーバは大抵の場合Oracleだ(私の仕事の中ではデファクトに近い位置だ)。そういう観点で見ると、すぎもとさんわたるさんの話も違って見えてくる。