我希望社区能够就我的一些关于 Linq to Sql 和其他 ORM 映射器的想法发表看法。
我喜欢 Linq to Sql 的想法，并且认为用你的本地开发语言表达数据访问逻辑（或者说一般的 CRUD 操作）比起处理 C# 和 SQL 之间的“阻抗不匹配”来说更方便。例如，要返回一个 ObjectDataSource 兼容的 Event 实例列表以供业务层使用，我们使用以下代码：
如果我使用旧的SQL-to-C#构造来实现这个，我将不得不创建一个Command类，添加EventID参数（使用字符串描述"@EventID"参数），将SQL查询字符串添加到Command类中，执行命令，然后使用(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），并且对于日期处理（例如 DateDiff）、"Having" 甚至 "Group By" 等 SQL 构造的支持非常笨拙（充其量）。
那还有什么替代方案呢？个人认为不需要像 Linq to Entities 这样的数据访问模型。我更愿意在 Visual Studio 中弹出一个窗口，输入和验证我的 SQL，然后按下一个按钮来生成或补充一个 C# 类来封装调用。既然你已经了解 SQL，你是否更喜欢像这样输入：
最终将得到一个EventData类，其中A)包含EventID和Title字段作为属性，B)具有一个工厂方法，该方法以“Location”字符串为参数并生成一个List<EventData>？您需要仔细考虑对象模型（上面的示例显然没有处理该模型），但仍使用SQL而消除阻抗不匹配的基本方法非常吸引我。
问题是：我错了吗？Microsoft是否应重写SQL基础架构，以便您不再需要学习SQL /关系数据管理？他们能以这种方式重写SQL基础设施吗？或者您认为在SQL之上加一个非常薄的层以消除设置参数和访问数据字段的痛苦已经足够了吗？
更新：我想将两个链接提升到顶部，因为我认为它们捕捉了我所追求的重要方面。首先，CodeMonkey指出一篇名为"计算机科学的越南战争"的文章。它需要一段时间才能开始，但非常有趣。其次，AnSGri指向Joel Spolsky的一篇更为突出的文章：泄漏抽象法则。它不完全相关，但很接近并且是一篇好文章。
更新2：我已经向ocdecio提供了“答案”，尽管这里有许多很好的答案，选择“正确”的答案纯粹是主观的。在这种情况下，他的答案符合我认为是当前技术状况下最佳实践的要求。然而，我完全希望这个领域会发展，所以事情可能会有所改变。我要感谢所有做出贡献的人，我已经给出了我认为给出了深思熟虑的答案的人点赞。
我喜欢 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查询字符串添加到Command类中，执行命令，然后使用(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），并且对于日期处理（例如 DateDiff）、"Having" 甚至 "Group By" 等 SQL 构造的支持非常笨拙（充其量）。
那还有什么替代方案呢？个人认为不需要像 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提供了“答案”，尽管这里有许多很好的答案，选择“正确”的答案纯粹是主观的。在这种情况下，他的答案符合我认为是当前技术状况下最佳实践的要求。然而，我完全希望这个领域会发展，所以事情可能会有所改变。我要感谢所有做出贡献的人，我已经给出了我认为给出了深思熟虑的答案的人点赞。