在一个项目中，我们使用可自动生成大量代码的可视化设计器实现了数据访问层 (DAL)（在我们的示例中：.NET 中的强类型 DataSet 和 DataSetTableAdapters）。
但是，使用源代码管理我发现在 DAL 中编辑和添加新内容很麻烦。我们已经开始通过手动编写 SQL 语句（在我们的例子中：ADO.NET SqlCommands 等）来编写新的数据访问，这对我来说似乎更易于编辑，尤其是通过源代码管理查看更改。
但我也担心混合数据访问的方法。你有什么建议？坚持使用自动生成方法，在需要更改时继续转换为“手动”SQL 语句，还是其他？
编辑：受到解决切换数据访问策略的一般问题的好答案的启发，我概括了问题的公式。
模型数据的处理不是非常面向对象的。我们使用 .NET DataTables 而不是自定义对象。
是的，坚持你所拥有的，并在必要和方便的时候进行重构。我讨厌不同意其他答案并混淆事物，但是通过使用另一个数据访问框架，您可能会用一个系统头痛换另一个系统。使用您感到舒适的基础知识。
直接使用“裸”ADO.NET 并在代码中手动完成所有 DAL 工作似乎需要付出很多努力。我肯定会推荐查看其他人（NHibernate、Subsonic 等）推荐的 OR-mapper。
如果您在 SQL Server 中使用后端并且您使用的是 .NET 3.0 或更高版本，您还可以查看 Linq2SQL（其死亡的谣言被大大夸大了）以获得更简单的场景（从数据库表到数据库层对象的 1:1 映射） ，或实体框架用于更高级的场景（大量表、域模型中的大量对象继承、复杂的映射场景）。
EF 最近受到了很多不好的批评，这只是部分合理，恕我直言，新版本 EF v4（将于今年或明年某个时候推出 .NET 4.0 和 VS 2010）看起来非常有希望。
马克
如果在转换为手动 ADO 或继续使用数据集+表适配器之间进行选择，我认为您最好还是使用数据集。通过使用它，您可以获得免费的 CRUD，从而减少了创建和维护没有任何价值的 sql 的时间。
顺便说一句，您提出问题的方式听起来也不像是要采用更加面向对象的方法，这可能是放弃数据集+表适配器方法的一个论据。
如果您要处理越来越复杂的业务逻辑，您可能还想对 OR-mapper + 纯对象域进行一些研究/原型设计。不过，它对 RAD 方法的效果较差。如果我是你，我会检查 Linq 2 sql（如果你有一个简单的模式/对象结构并且对对象和表之间的 1:1 映射感到满意）或 NHibernate。实体框架还不够成熟。下一个版本会更好，但仍然可能需要很长时间。
如果您要完全重写您的 DAL，那么也许您应该研究像Sprint.NET或NHibernate这样的持久性框架。
DAL 通常是任何应用程序中设计最过度的部分。保持简单并构建您现在需要的东西或合理预期很快需要的东西。与实际连接、读取和写入数据库的具体细节相比，SqlCommand、SqlDataReader 等仍然相对抽象。
也就是说，如果您只使用一种通用方法，您的代码将更具可读性。
...或来自Rob Conery的SubSonic :)
至少查看您可以在项目页面中找到的 3 个视频。