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