LINQ-to-SQL vs存储过程？

Question

LINQ-to-SQL vs存储过程？我在StackOverflow（LINQ初学者指南）上看了一下“LINQ 初学者指南”，但有一个后续问题：我们即将推出一个新项目，几乎所有的数据库操作都将是相当简单的数据检索（项目的另一部分已经编写了数据）。到目前为止，我们的大多数其他项目都使用存储过程来处理这些事情。但是，如果它更有意义，我想利用LINQ-to-SQL。所以，问题是：对于简单的数据检索，哪种方法更好，LINQ-to-SQL或存储过程？任何具体的专业人士或骗子？谢谢。

Answer 1

由于DBA多年来一直在努力的所有原因，我通常支持将所有内容都放在存储过程中。对于Linq，确实与简单的CRUD查询没有性能差异。

但在做出这个决定时要记住一些事项：使用任何ORM将您紧密地联系到您的数据模型。DBA无法自由更改数据模型，而无需强制更改已编译的代码。使用存储过程，您可以在一定程度上隐藏这些类型的更改，因为从过程返回的参数列表和结果集表示其合同，并且只要合同仍然满足，就可以更改内部条件。 。

而且，如果Linq用于更复杂的查询，调整数据库将变得更加困难。当存储过程运行缓慢时，DBA可以完全专注于代码，并且有很多选项，这样只要合同在他/她完成时仍然满足。

我已经看到很多很多情况，通过更改存储过程中的模式和代码来解决应用程序中的严重问题，而不会对已部署的已编译代码进行任何更改。

也许一个混合方法对Linq来说会很好吗？当然，Linq可用于调用存储过程。

Answer 2

对于基本数据检索，我会毫不犹豫地去找Linq。

自从搬到Linq后，我发现了以下优点：

1. 调试我的DAL从未如此简单。

2. 当架构更改无价时，编译时间安全性。

3. 部署更容易，因为所有内容都编译成DLL。不再管理部署脚本。

4. 因为Linq可以支持查询实现IQueryable接口的任何内容，所以您将能够使用相同的语法来查询XML，对象和任何其他数据源，而无需学习新的语法