我想让社区了解我对Linq到Sql和其他ORM映射程序的一些 idea .
我喜欢Linq to Sql，喜欢用自己的开发语言表达数据访问逻辑(或CRUD操作)，而不必处理C#和Sql之间的"阻抗不匹配".例如，要为业务层返回与ObjectDataSource兼容的事件实例列表，我们使用:
return db.Events.Select(c => new EventData() { EventID = c.EventID, Title = c.Title })
如果我要使用旧的SQL-to-C#构造实现这一点，我必须创建一个命令类，添加EventID参数(使用一个字符串来描述"@EventID"参数)，将SQL查询字符串添加到命令类，执行命令，然后使用(cast type)nwReader["FieldName"]提取每个返回的字段值，并将其分配给我的EventData类的一个新创建实例的成员(恶心).
所以，that是人们喜欢Linq/亚音速/等的原因，我同意.
然而，从更大的Angular 来看，我看到了一些错误的事情.我的感觉是，微软也看到了一些错误，这就是为什么他们killing Linq to SQL岁，并试图把人们从Linq转移到实体.只是，我认为微软是doubling-down on a bad bet.
那么，怎么了？
问题是，有architecture astronauts人，尤其是在微软，他们看到Linq to Sql并意识到它不是一个真正的数据管理工具:在C#中仍然有许多事情你无法轻松轻松地完成，他们的目标是fix it.你可以从Linq to Entities背后的野心中看到这一点，关于Linq的revolutionary种性质，甚至LinqPad challenge种性质的博客文章.
that的问题在于它假设SQL就是问题所在.也就是说，为了减少轻微的不适(SQL和Cα之间的阻抗不匹配)，微软提出了等效的太空服(完全隔离)，当一个创可贴(LINQ-SQL或类似的东西)会做得很好.
据我所见，开发人员非常聪明，能够掌握关系模型，然后在他们的开发工作中智能地应用它.事实上，我想进一步说，Linq到SQL、亚音速等等都是already too complex:.学习曲线与掌握SQL本身没有太大区别.因为，在可预见的future ，开发人员掌握了SQL和关系模型，所以我们现在要学习two种查询/CRUD语言.更糟糕的是，Linq通常很难测试(你没有一个查询窗口)，将我们从实际工作中移除一层(它生成SQL)，并且(最多)对SQL构造的支持非常笨拙，比如日期处理(例如DateDiff)、"Having"甚至"groupby".
替代方案是什么？就我个人而言，我不需要一个不同的数据访问模型，比如Linq到实体.我更喜欢在VisualStudio中弹出一个窗口，输入并验证我的SQL，然后按下按钮生成或补充一个C#类来封装调用.既然您已经了解SQL，您不想只输入以下内容:
Select EventID, Title From Events Where Location=@Location
最终得到一个EventData类，该类A)包含作为属性的EventID和Title字段，B)有一个工厂方法，该方法将"Location"字符串作为参数，并生成一个列表<；EventData>；？您必须仔细考虑对象模型(上面的示例显然没有涉及到这一点)，但仍然使用SQL同时消除阻抗不匹配的基本方法对我很有吸引力.
问题是:我错了吗？微软是否应该重写SQL基础设施，这样你就不必再学习SQL/关系数据管理了？Can他们用这种方式重写SQL基础设施吗？或者，您认为在SQL之上有一个非常薄的层来消除设置参数和访问数据字段的痛苦就足够了吗？
Update我想向高层推广两个链接，因为我认为它们抓住了我所追求的重要方面.首先，CodeMonkey指出了一篇题为《"The Vietnam of Computer Science."需要一段时间才能开始》的文章，但这是一篇非常有趣的文章.其次，安斯格里指出了乔尔·斯波尔斯基(Joel Spolsky)更著名的作品之一:The Law of Leaky Abstractions.这本书的主题并不明确，但它很接近，是一本很棒的书.
更新2:我已经给了ocdecio"答案"，尽管这里有很多很好的答案， Select "正确"的答案纯粹是主观的.在这种情况下，他的回答与我认为的在当前技术状态下的最佳实践相符.然而，我完全期待这一领域的发展，因此情况很可能会发生变化.我要感谢每一位做出贡献的人，我投票给了每一位我认为给出了深思熟虑的答案的人.