我看了一下StackOverflow上的“ LINQ初学者指南”（LINQ初学者指南），但是有一个后续问题：
我们将要启动一个新项目，其中几乎所有数据库操作都将是相当简单的数据检索（该项目的另一部分已经在写数据了）。到目前为止，我们的大多数其他项目都使用存储过程来处理此类事情。但是，如果更有意义，我想利用LINQ-to-SQL。
因此，问题是这样的：对于简单的数据检索，LINQ-to-SQL或存储的proc哪种方法更好？任何特定的赞成或反对？
谢谢。
我看了一下StackOverflow上的“ LINQ初学者指南”（LINQ初学者指南），但是有一个后续问题：
我们将要启动一个新项目，其中几乎所有数据库操作都将是相当简单的数据检索（该项目的另一部分已经在写数据了）。到目前为止，我们的大多数其他项目都使用存储过程来处理此类事情。但是，如果更有意义，我想利用LINQ-to-SQL。
因此，问题是这样的：对于简单的数据检索，LINQ-to-SQL或存储的proc哪种方法更好？任何特定的赞成或反对？
谢谢。
Answers:
LINQ优于sproc的一些优点：
LINQ vs sprocs的一些缺点：
安全性和可管理性也是人们争论的话题。
我曾经是一个存储专家，但是我开始倾向于LINQ作为总体上更好的选择。如果在某些地方存储过程明显更好，那么我可能仍会编写一个存储过程，但可以使用LINQ访问它。:)
if在事后用一些语句解决。
我通常支持将所有内容都放入存储过程中，因为DBA多年来一直在努力。对于Linq，确实很简单的CRUD查询不会有性能差异。
但是，在做出此决定时，请记住以下几点：使用任何ORM都会使您与数据模型紧密相关。在不强迫您更改编译代码的情况下，DBA不能自由更改数据模型。使用存储过程，您可以在某种程度上隐藏这些更改，因为从过程返回的参数列表和结果集代表其合同，并且只要可以遵守合同，就可以更改内部变量。 。
而且，如果将Linq用于更复杂的查询，则调整数据库将变得更加困难。当存储过程运行缓慢时，DBA可以完全将注意力集中在代码上，并且有很多选择，只是为了使合同完成后仍然可以满足合同要求。
我已经看到很多很多情况，通过更改存储过程中的模式和代码可以解决应用程序中的严重问题，而无需更改已部署的已编译代码。
Linq也许采用混合方法会更好？Linq当然可以用于调用存储过程。
Linq到Sql。
SQL Server将缓存查询计划，因此存储过程不会提高性能。
另一方面，从逻辑上讲，您的linq语句将成为应用程序的一部分并经过测试。Sproc总是有点分离，很难维护和测试。
如果我现在是从头开始开发新的应用程序，那么我只会使用Linq，而不会使用sproc。
对于基本数据检索，我会毫不犹豫地选择Linq。
自转到Linq以来，我发现了以下优点：
LINQ将膨胀过程缓存
如果应用程序正在使用LINQ to SQL，并且查询涉及使用长度可能高度可变的字符串，则对于每个可能的字符串长度，SQL Server过程高速缓存将使用一个版本的查询来肿。例如，考虑以下针对AdventureWorks2008数据库中的Person.AddressTypes表创建的非常简单的查询：
var p =
from n in x.AddressTypes
where n.Name == "Billing"
select n;
var p =
from n in x.AddressTypes
where n.Name == "Main Office"
select n;如果这两个查询都运行，我们将在SQL Server过程高速缓存中看到两个条目：一个与NVARCHAR（7）绑定，另一个与NVARCHAR（11）绑定。现在想象一下，如果有成百上千个不同长度的输入字符串。对于完全相同的查询，过程缓存将不必要地充满各种不同的计划。
此处更多内容：https : //connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363290
我认为临LINQ的论点似乎来自没有数据库开发历史的人（通常）。
尤其是在使用诸如VS DB Pro或Team Suite之类的产品时，此处提出的许多参数都不适用，例如：
难以维护和测试：VS提供完整的语法检查，样式检查，引用和约束检查等等。它还提供完整的单元测试功能和重构工具。
LINQ无法进行真正的单元测试，因为（在我看来）它无法通过ACID测试。
在LINQ中调试更容易：为什么？VS允许从托管代码中完全介入，并对SP进行常规调试。
编译为单个DLL而不是部署脚本：VS再一次获得了成功，可以构建和部署完整的数据库或进行数据安全的增量更改。
不必通过LINQ学习TSQL：不，您不需要，但是您必须学习LINQ-好处在哪里？
我真的不认为这是一种好处。从理论上讲，能够孤立地更改某些东西听起来不错，但是仅仅因为更改满足了合同并不意味着它返回了正确的结果。为了能够确定什么是正确的结果，您需要上下文，并且可以从调用代码中获得该上下文。
嗯，松耦合的应用程序是所有优秀程序员的最终目标，因为它们确实可以提高灵活性。能够孤立地更改事物真是太棒了，而您的单元测试将确保它仍然返回适当的结果。
在所有人不高兴之前，我认为LINQ占有一席之地，并且拥有美好的未来。但是对于复杂的，数据密集型应用程序，我认为它不能代替存储过程。我是今年TechEd的MVP所回应的观点（他们将保持匿名）。
编辑：LINQ to SQL存储过程方面的事情是我仍然需要阅读更多的内容-取决于我发现我可能会改变上述的内容；）
LINQ是新的，并且拥有自己的位置。并非发明LINQ来代替存储过程。
在这里，我将仅针对“ LINQ to SQL”来关注一些性能神话和缺点，当然，我可能完全错了;-)
（1）人们说LINQ语句可以在SQL Server中“缓存”，因此它不会失去性能。部分正确。“ LINQ to SQL”实际上是将LINQ语法转换为TSQL语句的运行时。因此，从性能的角度来看，硬编码的ADO.NET SQL语句与LINQ没有区别。
（2）以一个示例为例，客户服务UI具有“帐户转帐”功能。此函数本身可以一次更新10个DB表并返回一些消息。使用LINQ，您必须构建一组语句并将它们作为一批发送到SQL Server。转换后的LINQ-> TSQL批处理的性能几乎无法与存储过程匹配。原因？因为您可以使用内置的SQL事件探查器和执行计划工具来调整“存储过程”中语句的最小单元，所以您不能在LINQ中这样做。
关键是，当谈论单个数据库表和少量数据CRUD时，LINQ与SP一样快。但是对于更复杂的逻辑，存储过程的性能更可调整。
（3）“ LINQ to SQL”使新手很容易引入性能猪。任何TSQL高级人员都可以告诉您何时不使用CURSOR（基本上，在大多数情况下，您不应该在TSQL中使用CURSOR）。使用LINQ和带有查询的迷人的“ foreach”循环，对于新手来说，编写这样的代码非常容易：
foreach(Customer c in query)
{
c.Country = "Wonder Land";
}
ctx.SubmitChanges();您可以看到这个简单的体面代码是如此吸引人。但实际上，.NET运行时只是将其转换为更新批处理。如果只有500行，则这是500行TSQL批处理；如果有一百万行，这很受欢迎。当然，有经验的用户不会使用这种方式来完成这项工作，但重点是，以这种方式掉入很容易。
LINQ在特定于应用程序的数据库和小型企业中绝对占有一席之地。
但是，在大型企业中，中央数据库充当许多应用程序的通用数据中心，我们需要抽象。我们需要集中管理安全性并显示访问历史。我们需要能够进行影响分析：如果我为满足新的业务需求而对数据模型进行少量更改，则需要更改哪些查询以及需要重新测试哪些应用程序？视图和存储过程给了我这一点。如果LINQ能够做到所有这些并提高我们的程序员的生产力，那么我将欢迎它-有没有人有在这种环境下使用它的经验？
恕我直言，RAD = LINQ，RUP =存储的过程。我曾在一家大型的《财富》 500强公司工作了很多年，在包括管理层在内的许多层次上，坦率地说，我永远不会雇用RUP开发人员来进行RAD开发。他们是如此孤立，以至于他们在该过程的其他层次上做什么的知识非常有限。在孤立的环境中，通过非常特定的入口点授予DBA对数据的控制权是有意义的，因为其他人坦率地说并不知道完成数据管理的最佳方法。
但是大型企业在发展领域的步伐缓慢而痛苦，这是极其昂贵的。有时候，您需要更快地移动以节省时间和金钱，而LINQ则提供了更多功能。
有时我认为DBA偏爱LINQ，因为他们认为LINQ威胁到他们的工作安全。但这就是野兽的本质，女士们，先生们。
我认为您需要使用proc进行真正的处理。
A）用linq编写所有逻辑意味着您的数据库用处不大，因为只有您的应用程序才能使用它。
B）我仍然不相信对象建模总比关系建模好。
C）用SQL测试和开发存储过程比在任何Visual Studio环境中进行编译编辑周期要快得多。您只需编辑，按F5并按选择，即可开始比赛。
D）管理和部署存储过程比程序集更容易..您只需将文件放在服务器上，然后按F5 ...
E）Linq to sql有时在您不期望的时候仍会编写糟糕的代码。
老实说，我认为最终的目的是让MS增强t-sql，以便它可以隐式地执行linq的联接投影。例如，t-sql应该知道您是否要执行order.lineitems.part。
LINQ不禁止使用存储过程。我已经在LINQ-SQL和LINQ-storedproc中使用了混合模式。就个人而言，我很高兴我不必编写存储的过程.... pwet-tu。
我假设你是说Linq To Sql
对于任何CRUD命令，很容易分析存储过程与任何技术的性能。在这种情况下，两者之间的任何差异都可以忽略不计。尝试对超过100,000个选择查询的5个（简单类型）字段对象进行性能分析，以了解是否存在真正的差异。
另一方面，真正的交易突破点将是您是否愿意将业务逻辑放在数据库中，这是反对存储过程的一个问题。
倾向于LINQ的所有这些答案都主要是在讨论“易于开发”，它与编码质量差或编码的惰性无关。我只是那样而已。
一些优点或Linq，我在这里读为，易于测试，易于调试等，但是这些与最终输出或最终用户无关。这总是会给最终用户带来性能上的麻烦。将很多东西加载到内存中然后在使用LINQ时应用过滤器的意义何在？
再次使用TypeSafety，请注意“我们要小心避免错误的类型转换”，这也是我们试图通过使用linq改善的质量较差的问题。即使在那种情况下，如果数据库中的任何内容发生了变化，例如String列的大小，那么linq也需要重新编译，否则就不会是类型安全的。
尽管在使用LINQ时我们发现它很好，很甜，很有趣，但它具有使开发人员变得懒惰的剪切缺点：)，并且与存储的Procs相比，它的性能差（可能更糟）是1000倍。
别再懒了。我很努力 :)
Create PROCEDURE userInfoProcedure
-- Add the parameters for the stored procedure here
@FirstName varchar,
@LastName varchar
AS
BEGIN
SET NOCOUNT ON;
-- Insert statements for procedure here
SELECT FirstName , LastName,Age from UserInfo where FirstName=@FirstName
and LastName=@FirstName
END
GOhttp://www.totaldotnet.com/Article/ShowArticle121_StoreProcBasic.aspx