データベースアクセス関連のコントロールとMVCモデル

最近になって、Visual Studio .NETで本を見ながらADO.NETとかDataSetとかDataGridを動かし始めたのですが、どうも気になることがあります。
アプリケーション構築の考え方として世の中には「n階層システム」とか「MVCモデル」とかありますよね。ところが、Visual Studio .NETの「データ」に表示される各種コントロールはどうもこれと相反しているように思います。

Windowsフォーム上のDataGridコントロールにデータベースの内容を表示させたい場合は、「データ」タブにある各種コントロールを使用するのが一番手っ取り早いです。
しかし、SQLConnectionというコントロールをフォームにドロップして接続の設定を行い、それに関連したDataAdapterやDataSetをまたフォームにドロップして、それをDataGridのソースにつなげて・・・という感じで作っていくと、データベースアクセスの部分と画面表示部分が混在してしまい、MVCとかの考え方から見ると「良くない」のとかなぁと感じるのです。
もちろん、コントロールを使わずに、コードでDataSetを生成したりSQL Serverに接続したりは出来るので、そうすればしっかりとViewとModelを分離することは出来るのですが、そうすると便利なGUIの設定ツールが使えない(ですよね?)。
これはDataSetやDataAdapterをモデルと見なしてやれば、気分的には割り切れるような気もします。データベースアクセス以外のビジネスロジックは他のクラスに追い出すとしてですね。でも、ある特定のテーブルとフォームが密接にからみつくのは変わらないので、それでもよし、なのかもっと汎用的にするために、コントロールは使わずにクラスを自分でNewしていくかは、やる内容次第でしょうか?
このあたりってみなさんどんな風に考えてるんだろうなぁ。

関連する記事

VistaでVisual Studioを動かすときの注意点 いつのまにやらVisual Studio 2005 Express Editionが一般公開されている だぁ?おそい! ThinkPad起動が遅いよ NUnitを便利に使うテンプレートとコードスニペット 結局、Standardを買うしかない?! Visual Studio 2005 リファクタリング機能はいい! Monoすげー あれ?ExpressでClick-Once使えるんだが・・・ MSDNにしとけば良かったかな