将SPROCS迁移到LINQ-to-SQL预编译的动态SQL？

Question

我想将现有的存储过程转换为LINQ-to-SQL预编译的动态SQL。有谁知道最好的方法来做到这一点？

我提到预编译，因为我相信我可以获得性能提升 - 与SPROC不一样，但类似，正确吗？还有LINQ-to-SQL预编译的动态SQL，我得到强类型的字段等。这些假设是否正确？

此外，它可能不可用，但有没有办法将我的存储过程自动转换为LINQ到SQL？

Answer 1

不，我不同意你的假设。

1 /存储过程将提供至少与LINQ-to-SQL一样好的（如果不是更好的话）性能。通过转移到LINQ到SQL，您不会看到任何性能提升

2 /您可以使用现有存储特效获取强类型字段。我相信你通过使用DataSets（从内存）得到了这个，但是我确信如果你创建一个LINQ到SQL类，并且简单地将Stored Procedures拖到设计器上，你会得到它。代码生成器将为每个存储过程创建强类型并正确命名的ReturnObjects。

如果你有现有的存储过程，那么我不会打扰他们转换成LINQ。

Answer 2

将所有存储过程转换为LINQ to SQL将是一项重要工作，具体取决于您拥有多少存储过程。我会建议，这是我们在这里所做的是你设置一个日期开始与LINQ to SQL，而不是存储过程前进。这样，所有新功能都将使用LINQ to SQL，如果您回到旧功能并添加新功能，而不是将其转换为LINQ to SQL。

您还可以将存储过程导入到LINQ to SQL中，并将它们用作函数。解决这个问题的最佳方式是逐步缓慢地移动一个功能，并最终全部转换。

至于性能提升，你可能不会马上看到任何巨大的收益。这将取决于您的存储过程如何优化？ LINQ to SQL生成相当高效的SQL代码，但不是在所有情况下，有时您将不得不编写一些SQL来获得所需的性能。我发现很多与我一起工作的开发人员并没有在存储过程中编写非常高效的SQL代码。有时候是因为时间有限，有时候是因为他们不知道更好。在这些情况下，LINQ to SQL倾向于更好地执行，因为SQL生成比开发人员可以自己写的更加优化。我发现的另一个有趣的观点是，LINQ to SQL倾向于写比LINQ to Entities更高效的SQL，只是要记住。

最后，我不知道任何将存储过程转换为LINQ to SQL的工具，但实际转换不是很困难，LINQ与SQL非常相似。

希望这会有所帮助。