あくまで持論というか、最近思うことだと思って聞いていただけると良いかと思います。
.NET FrameworkのADO.NETの中核オブジェクトとして、DataSetというものがあります。
まぁ、簡単に言えば、データベースにあるテーブルと同じような構造を持つクラスです。
更新部分の問題はとりあえず置いといて…
クライアントでDataSetを扱う場合どうするか、ということです。
クライアント側の処理がある程度複雑だと思っていただければと良いかと思います。
DataSet（というかDataTable）に格納されている値をクライアントで画面等に表示する場合、格納値を何らかの形でコントロール側に渡す必要があります。
手段はいくつかあると思います。
１．クライアントで直接データセットを参照して、一つ一つコントロールに値を入れていく
２．BindingSourceのDataSourceにDataSetを渡して、データバインドを行う
３．画面とDataSetをつなぐ別のオブジェクトを使って、データバインドを行う
まぁ、１はないでしょう。
ソースが冗長になりますし、プログラムの表現力に問題があります。
また、どのコントロールがどの値を示すかを把握する労力が大きすぎます。
２の方法は、WindowsFormを前提としてしまっていますが＾＾；
コントロールのプロパティに、DataSetに格納されているデータをそのまま表示できるという利点があります。
しかし、データバインドを用いたとしても問題があります。
もし、DataSetに格納すべき値に複雑な要件があるとした場合、実装が難しくなります。
（コントロールに入力された値から、様々な判定が必要な場合とか、他の値を変更しなければならない場合とか）
値の検証をイベントに頼ることになり、その管理が複雑になります。
そして、今作っているシステムは２が前提という＞＜
で、３の方法です。
概ね、INotifyPropertyChangedインターフェイスを実装したオブジェクトを用いることとなります。
この方法を採用する場合、自動生成されたDataSet以外に、データバインド用のクラスを作成せねばならないという欠点があります。
しかし、プロパティ名等を自由に選択でき、表現力は間違いなく一番大きいです。
DataSetでNullableを扱えないという問題も、自作のオブジェクトなら完全にクリアできます。（実装次第で）
それに、WPFを採用するなら３以外は考えられないです。
３がいいって思えるのも、２の実装をやってきた後にWPF（というかMVVMパターン）に触れたおかげです。
そして最近ドメイン駆動設計の本を読んでいるおかげでもあります。
具体例がないと、この辺りの話は難しいですよね＾＾；
でも、アメブロってソースコード掲載しづらくて…
お引越しでもしようかと思った今日このごろ。