我希望社区能够了解我对 Linq to Sql 和其他 ORM 映射器的一些想法。
我喜欢 Linq to Sql 以及用本机开发语言表达数据访问逻辑（或一般的 CRUD 操作）的想法，而不必处理 C# 和 SQL 之间的“阻抗不匹配”。例如，要为业务层返回与 ObjectDataSource 兼容的事件实例列表，我们使用：
return db.Events.Select(c => new EventData() { EventID = c.EventID, Title = c.Title })
如果我要使用旧的 SQL 到 C# 构造来实现此功能，我必须创建一个 Command 类，添加 EventID 参数（使用字符串来描述“@EventID”参数），将 SQL 查询字符串添加到Command 类，执行命令，然后使用 (cast-type)nwReader["FieldName"] 提取每个返回的字段值并将其分配给我的 EventData 类新创建的实例的成员（恶心）。
So, that这就是人们喜欢 Linq/SubSonic/etc 的原因。并且我同意。
然而，从更大的角度来看，我发现了一些错误的事情。我的感觉是微软也看到了一些问题，这就是为什么他们杀死 Linq to SQL http://codebetter.com/blogs/david.hayden/archive/2008/10/31/linq-to-sql-is-dead-read-between-the-lines.aspx并试图将人们转移到 Linq to Entities。只是，我认为微软在一个错误的赌注上加倍下注。
那么，到底出了什么问题呢？
问题是有建筑宇航员 http://www.joelonsoftware.com/articles/fog0000000018.html尤其是在 Microsoft，他们研究了 Linq to Sql 并意识到它不是一个真正的数据管理工具：仍然有很多事情在 C# 中无法轻松轻松地完成，他们的目标是fix it.您可以在 Linq to Entities 背后的雄心壮志中看到这一点，以及关于革命性的 http://blogs.msdn.com/adioltean/archive/2005/09/13/465471.aspxLinq 的本质，甚至LinqPad 挑战 http://www.linqpad.net/Challenge.aspx.
问题是that是它假设 SQL 是问题所在。也就是说，为了减少轻微的不适（SQL 和 C# 之间的阻抗不匹配），微软提出了相当于宇航服（完全隔离）的方案，而创可贴（Linq to SQL 或类似的东西）就可以了。
据我所知，开发人员非常聪明，能够掌握关系模型，然后在开发工作中明智地应用它。事实上，我会更进一步说 Linq to SQL、SubSonic 等是已经太复杂了：学习曲线与掌握 SQL 本身没有太大区别。因为在可预见的未来，开发商must掌握了SQL和关系模型，我们现在面临着学习two查询/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?您必须仔细考虑对象模型（上面的示例显然没有涉及到这一点），但在消除阻抗不匹配的同时仍然使用 SQL 的基本方法对我很有吸引力。
问题是：我错了吗？ Microsoft 是否应该重写 SQL 基础架构，以便您不再需要学习 SQL/关系数据管理？Can他们以这种方式重写 SQL 基础设施？或者您是否认为 SQL 之上的一个非常薄的层来消除设置参数和访问数据字段的痛苦就足够了？
Update我想将两个链接提升到顶部，因为我认为它们抓住了我所追求的重要方面。首先，CodeMonkey指出一篇文章，题为“计算机科学的越南”。 http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx开始需要一段时间，但读起来非常有趣。其次，AnSGri 指出了乔尔·斯波尔斯基 (Joel Spolsky) 更著名的作品之一：抽象泄漏法则 http://www.joelonsoftware.com/articles/LeakyAbstractions.html。它不完全是主题，但很接近并且是一本很好的读物。
更新2：我已经给了ocdecio“答案”，尽管这里有很多很好的答案，并且“正确”答案的选择纯粹是主观的。在这种情况下，他的答案与我认为的考虑到当前技术状况的真正最佳实践相一致。然而，这是一个我完全期望发展的领域，因此事情很可能会发生变化。我要感谢所有做出贡献的人，我对所有我认为给出了深思熟虑答案的人都投了赞成票。
