我希望社区了解我对 Linq to Sql 和其他 ORM 映射器的一些想法。
我喜欢 Linq to Sql 以及用您的本地开发语言表达数据访问逻辑（或一般的 CRUD 操作）的想法，而不是必须处理 C# 和 SQL 之间的“阻抗不匹配”。例如，要为业务层返回与 ObjectDataSource 兼容的 Event 实例列表，我们使用：
return db.Events.Select(c => new EventData() { EventID = c.EventID, Title = c.Title })
如果我要使用旧的 SQL-to-C# 结构来实现它，我必须创建一个 Command 类，添加 EventID 参数（使用字符串来描述“@EventID”参数），将 SQL 查询字符串添加到命令类，执行命令，然后使用 (cast-type)nwReader["FieldName"] 提取每个返回的字段值并将其分配给我的 EventData 类的新创建实例的成员 (yuck)。
所以，这就是人们喜欢 Linq/SubSonic/等的原因。并且我同意。
然而，从更大的角度来看，我看到了许多错误的事情。我的感觉是微软也看到了一些错误，这就是为什么他们正在杀死 Linq to SQL并试图将人们转移到 Linq to Entities。只是，我认为微软正在加倍下注。
那么，有什么问题呢？
问题是有些架构宇航员，尤其是在微软，他们看到 Linq to Sql 并意识到它不是一个真正的数据管理工具：仍然有很多事情你不能轻松地在 C# 中轻松完成，他们的目标是修复它. 您可以在 Linq to Entities 背后的雄心壮志、关于 Linq革命性的 博客文章甚至是LinqPad 挑战中看到这一点。
问题在于它假设 SQL 是问题所在。也就是说，为了减少轻微的不适（SQL 和 C# 之间的阻抗不匹配），微软提出了相当于太空服（完全隔离），而创可贴（Linq to SQL 或类似的东西）就可以了。
据我所知，开发人员非常聪明，能够掌握关系模型，然后在他们的开发工作中智能地应用它。事实上，我会更进一步地说，Linq to SQL、SubSonic 等已经太复杂了：学习曲线与掌握 SQL 本身并没有太大区别。由于在可预见的未来，开发人员必须掌握 SQL 和关系模型，我们现在面临学习两种查询/CRUD 语言。更糟糕的是，Linq 通常很难测试（你没有查询窗口），将我们从我们正在做的实际工作中移除了一层（它生成 SQL），并且对 SQL 结构（充其量）非常笨拙的支持，例如日期处理（例如 DateDiff）、“Having”甚至“Group By”。
什么是替代方案？就个人而言，我不需要像 Linq to Entities 这样的数据访问模型。我更喜欢简单地在 Visual Studio 中弹出一个窗口，输入并验证我的 SQL，然后按一个按钮生成或补充一个 C# 类来封装调用。既然您已经了解 SQL，您是否更愿意只输入如下内容：
Select EventID, Title From Events Where Location=@Location
并最终得到一个 EventData 类，A) 包含 EventID 和 Title 字段作为属性，B) 有一个工厂方法，该方法将“Location”字符串作为参数并生成 List<EventData>? 您必须仔细考虑对象模型（上面的示例显然没有处理该问题），但在消除阻抗不匹配的同时仍然使用 SQL 的基本方法对我很有吸引力。
问题是：我错了吗？微软是否应该重写 SQL 基础架构，以便您不必再学习 SQL/关系数据管理？ 他们能以这种方式重写 SQL 基础架构吗？还是您认为在 SQL 之上的一个非常薄的层来消除设置参数和访问数据字段的痛苦就足够了？
更新我想将两个链接推广到顶部，因为我认为它们抓住了我所追求的重要方面。首先，CodeMonkey 指出了一篇题为“计算机科学的越南”的文章。 开始需要一段时间，但读起来非常有趣。其次，AnSGri 指出了 Joel Spolsky 最杰出的作品之一：泄漏抽象法则。它不完全是主题，但它很接近并且是一本很好的读物。
更新 2：我已经给 ocdecio 提供了“答案”，尽管这里有很多很好的答案，而“正确”答案的选择纯粹是主观的。在这种情况下，他的回答与我认为在当前技术状态下真正的最佳实践相一致。然而，这是一个我完全期望发展的领域，所以事情很可能会发生变化。我要感谢所有做出贡献的人，我投票给了我认为给出了深思熟虑的答案的每个人。