暗黙的型付け（その３） http://blogs.wankuma.com/rti/archive/2007/12/27/114850.aspx
で思い出したのですが....型付DataSetの事です。好き嫌いの分かれる機能のようです。
好派: インテリセンスが使える、コントロールと相性が良い、ノンコーディングで雛形が作れる、その他
嫌派: コストが重い、自動生成されたDesigner.vbが気に入らない、デザイン(XML)とVBの二元管理がイヤ、NULLの扱いが煩雑、その他
コスト高は仕組み上、仕方ないなぁと思います。項目か100個あれば10000行位になりますが。
いずれも納得ができます。私はあまり使わないけれど推奨派です。(矛盾してないつもり)
単純に DataSet と DataTableの複合クラスなので自力で構築しても良いと思います。XSDデザイナーは使えないですが、独自制約が付加できて便利だったりします。
もっとも、私は不特定のテーブルを対象にした物を作ることが多いので使えないことが多いです。
(補足)定義できるDataTypeがコンボBoxで表示される型に限定されると誤解している人がいましたが、他の型も使えます。System.Data.SqlTypes.SqlInt32やSystem.Data.SqlTypes.String も使えます。
XSDを理解した上で、好き嫌いを評価して欲しいのですが、知らないで使わない人も見かけます。これは勿体無い。
使わない理由のひとつに「テーブル項目が頻繁に変わるのでXSDの保守が面倒」というのを聞きました。
疑問を感じます。テーブル項目って頻繁に変わるものなの?
設計が終われば項目は確定するものではないでしょうか。未確定部分があれば、Wrapした形で開発に影響しないようにしたいものです。
開発途中で項目変更が発生するのは設計バグでしょう。手戻り一杯のシステムになり開発工数の増大に直結します。
設計終了までは開発しないのが本筋と思います。....とは言うものの現実には突入するプロジェクトもあるし......
IDEのお陰で、UI部分の変更やDBの項目変更も手軽にできますが、手軽だから頻繁に変更しても良いことにはなりません。
開発時のUIの変更はありがちですが、TABLE項目の変更をこれと同列と意識している設計者がいるのは疑問を持ちます。
もちろん、手探りで何かを作るときや開発と設計を繰り返すスタイルの時は当てはまりませんが、業務プロシェクでは稀なケースでしょう。
十分な設計は実装を幸福にします。逆も真で、逆のケースが多い気がするのは何故なんだろう??