我希望社区对Linq to Sql和其他ORM映射器有一些想法。
我喜欢Linq和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 / etc这样的人。并且我同意。
但是，从更大的角度看，我发现许多错误。我的感觉是，Microsoft也看到了错误，这就是为什么他们杀死Linq to SQL并试图将人们转移到Linq to Entities。只是，我认为微软正在加倍下注。
那么，怎么了？
问题在于，有一些架构宇航员，尤其是Microsoft的宇航员，他们研究了Linq to Sql并意识到这不是一个真正的数据管理工具：在C＃中，您仍然无法轻松完成许多事情，他们的目标是修复它。 您会看到这体现在Linq to Entities背后的野心，有关Linq的革命性甚至LinqPad挑战的博客文章中。
而这个问题是在于，它假定SQL的问题。也就是说，为了减轻轻微的不适（SQL和C＃之间的阻抗不匹配），Microsoft建议在创可贴（Linq to SQL或类似的东西）就可以的情况下等效于太空服（完全隔离）。
据我所知，开发人员足够聪明，可以掌握关系模型，然后将其智能地应用于开发工作中。实际上，我再说一遍，Linq to SQL，SubSonic等已经太复杂了：学习曲线与掌握SQL本身并没有太大不同。由于在可预见的将来，开发人员必须掌握SQL和关系模型，因此我们现在面临学习两种查询/ CRUD语言的问题。更糟糕的是，Linq通常很难测试（您没有查询窗口），将我们从正在执行的实际工作中删除了一层（生成SQL），并且对SQL构造（例如，最多）的支持非常笨拙日期处理（例如DateDiff），“具有”甚至“分组依据”。
有什么选择？就个人而言，我不需要像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的基本方法对我很有吸引力。
问题是：我错了吗？Microsoft是否应该重写SQL基础结构，以便您不必再学习SQL /关系数据管理？ 他们可以以此方式重写SQL基础结构吗？还是您认为，在SQL之上的一个非常薄的层足以消除设置参数和访问数据字段的麻烦？
更新我想将两个链接提升到顶部，因为我认为它们抓住了我所追求的重要方面。首先，CodeMonkey指出了一篇题为“计算机科学的越南”的文章。 入门需要一些时间，但阅读起来很有趣。其次，AnSGri指出了Joel Spolsky最著名的作品之一：泄漏抽象定律。它并不完全是主题，但是它很接近并且很值得一读。
更新2：尽管这里有很多很棒的答案，但我给了ocdecio一个“答案”，而“正确”答案的选择纯粹是主观的。在这种情况下，鉴于当前的技术水平，他的回答与我认为的确是最佳实践相吻合。我完全希望这是一个可以发展的领域，因此情况可能会发生变化。我要感谢所有做出贡献的人，我已经投票给所有我认为给出了深思熟虑的人。