ライブラリィを見る視点

System.ComponentModel はすでに死んだ、IDisposableも死につつある

私はTableAdaptorは使わないので、同クラスに特に感想はない。というかTableAdaptorはおろか、データセット(DataSet)も含めて、Visual Studio 2005のデザイナで生成されたコードにはできるだけ頼らないでアプリケーションを開発することを念頭に置いていたりする。ASP.NETを仕事の対象にしていないせいもあるだろうが、そのように決めた理由の一つに.NET Framework 2.0が導入したPartialクラスの存在がある。
Visual Studio 2005はデザイナで生成されたコード(C#であれば〜.Designer.cs等)はユーザが触らない、拡張しないことを前提にしているが、Partialクラスの導入でその方向はより強くなったと感じる。Visual Studio 2005のβ1からβ2への遷移で経験したが、デザイナが吐くコードは、予告無しに仕様が変更される可能性が非常に高い訳で、ずっと今のままであることを当てには出来ないのが嫌だ。
あと、私はADO.NETはJDBC等と同様にデータアクセス層のミドルウェア的なフレームワークと考えている。いろいろな戦略や狙いもあるだろうが、データアクセス層のフレームワークなのであればVisual Studioのデザイナ機能からアクセスされることを前提には設計して欲しくないし、余計なインタフェースの実装はインタフェース汚染と考えている位だ。
むろんデザイナによるユーザエクスペリエンスは、IDEの売り文句として非常に重要であり、それらの機能は必要だろう。でも、そのためにはADO.NETとVisul Studioをブリッジするための層があればもっとすっきりするのになぁ、と勝手に思うわけだ。

こんな考えなので、私は一般的な.NET使い、Visual Studio 2005使いから見たら異端であり、おいしい所を食べない食わず嫌いだとその筋の方々からは後ろ指を指されると思うのだが、なんというか、ラィブラリィを俯瞰する際に重きを置くポイントは人それぞれなのだなと興味深かった。(だからこそ万能のフレームワーク、ラィブラリィなど無いのだなと思う)

話題とは関係ないがここまで書いたところで、JavaのIDEの黎明期にJBuilderが好きだった一番の理由は、他のIDE、例えばVisual Cafe等と違って、開発者が認知しないコードを一切吐かないことだったことを思い出した。

追記: だからといってADO.NETがIComponentを正しく扱わないのは別に問題は無いとは決して書いていないので念のため。フレームワーク内で終始一貫していることが第一命題であり、菊池さんの書いていることは判る。