プロジェクトでは、多くのコード（この場合は.NETの強い型のDataSetsとDataSetTableAdapters）を自動生成するビジュアルデザイナーを使用してデータアクセス層（DAL）を実装しました。
ただし、ソース管理を使用すると、DALを編集して新しいものを追加するのが面倒だと思います。SQLステートメント（この場合はADO.NET SqlCommandsなど）を手動で記述して、新しいデータアクセスのコーディングを開始しました。これは、編集、特にソース管理を介した変更の確認に適しています。
しかし、データアクセスの方法が混在することも心配です。あなたは何を提案しますか？自動生成方法に固執し、変更が必要な場合は「手動」SQLステートメントへの変換を続行しますか？
編集：データアクセス戦略の切り替えの一般的な問題に対処する素晴らしい答えに触発されて、私は質問の定式化を一般化しました。
モデルデータの処理は、オブジェクト指向ではありません。カスタムオブジェクトの代わりに.NETDataTablesを使用します。
はい、あなたが持っているものに固執し、必要かつ便利なようにリファクタリングします。私は他の答えに反対し、物事を混乱させるのは嫌いですが、別のデータアクセスフレームワークを使用することで、あるシステムの頭痛の種を別のシステムの頭痛の種と交換する可能性があります。あなたが快適であるあなたの基本に行きなさい。
手動ADOに変換するか、データセット+テーブルアダプターを引き続き使用するかを選択する場合は、データセットを使用する方がよいと思います。これを使用することで無料のCRUDを取得できるため、価値のないsqlの作成と保守にかかる時間が短縮されます。
ちなみに、質問の言い回しとしては、よりオブジェクト指向のアプローチを採用しているようには思えません。これは、データセット+テーブルアダプターのアプローチから離れることの議論になる可能性があります。
You might want to do some research/prototyping into the OR-mapper + pure objects domain as well, if you have increasingly complex business logic to handle. It's less effective for the RAD approach though. I'd check out Linq 2 sql (if you have a simple schema/object structure and are happy with 1:1 mapping between object and table) or NHibernate if I were you. Entity Framework isn't mature enough. The next version will be better, but it is still potentially a long time coming.
まっすぐな「裸の」ADO.NETに移行し、コードですべてのDAL作業を手動で行うのは、大変な作業のように思えます。他の人（NHibernate、Subsonicなど）によって推奨されているようなORマッパーを確認することを強くお勧めします。
SQLServerのバックエンドで.NET3.0以降を使用している場合は、Linq2SQL（その死の噂は非常に誇張されています）を調べて、より単純なシナリオ（データベーステーブルからデータベースレイヤーオブジェクトへの1：1マッピング）を探すこともできます。 、またはより高度なシナリオのEntity Framework（多数のテーブル、ドメインモデルでの多数のオブジェクト継承、複雑なマッピングシナリオ）。
EFは最近多くの悪いラップを得ていますが、それは部分的に正当化されています、IMHO、そして新しいバージョン、EF v4（.NET4.0とVS2010で、今年または来年のいつかでリリースされる予定です）は本当に有望に見えます。
マーク
DALを完全に書き直している場合は、Sprint.NETやNHibernateなどの永続性フレームワークを調べる必要があります。
DALは通常、アプリケーションの中で最も過剰に設計された部分です。シンプルに保ち、今必要なものを構築するか、すぐに必要になると合理的に予想します。SqlCommand、SqlDataReaderなどは、データベースへの実際の接続、データベースからの読み取り、データベースへの書き込みの要点と比較すると、依然として比較的抽象的です。
とはいえ、一般的なアプローチを1つだけ使用すると、コードが読みやすくなります。