2006-06-09

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

.NET OOP

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

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

バックエンドが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だ(私の仕事の中ではデファクトに近い位置だ)。そういう観点で見ると、すぎもとさんやわたるさんの話も違って見えてくる。

2006-06-09

工夫する余地

.NET OOP

C#2.0時代のゲームプログラミング(38) - やねうらお−よっちゃんイカ(ry

.NET関係ではコーディング指針を示した書籍が少ない。(というか私は日本語で書かれているものは寡聞にして知らない)　C#はC++よりはどちらかと言えばJavaに近いので定評のあるJava本にはC#プログラマが読むに値すべき内容が書かれているのだなと思った。

"Effective Java"が出た当時、Javaが面白いなと思ったのはコーディングやイディオムに少し気をつけることによって、プログラムの性能や効率が改善されたり、スマートで美しくなったりすることだった。GCを標準で装備する現代の高級言語においても、CやC++同様にまだ「工夫する余地」があるってのが新鮮だったのである。
私は、C#のコーディング本が少ないのは、純粋に.NET本の絶対量が少ないという理由の他に、C#(+.NET CLR)はJava(+JVM)に比べても「工夫する余地」がさほど無い言語処理系だからではないかと思っている。
もちろんやねうらおさんが書いているように"Effective Java"のかなりの部分はC#にも適用できるのだが、改善の幅(Effectiveness)はJavaのほうが圧倒的に大きい(当時大きかった)のだと思うのだ。

言語の完成度とも関連するのだろうが、今後プログラマが「工夫する余地」ってのはどんどん少なくなっていくだろう、という説があり、最もだとは思うのだが、一方では、言語は動的な方向に進んでいるので別な部分での「工夫する余地」ってのが生まれていくという説もある。どっちも本当のような気がする。

追記:発展途上の言語(+処理系)にときめく人達は、この「工夫する余地」が多く残っているからではないだろうか。