linq2sql与存储过程

如果你把代码放入一个存储过程中,你就已经把它与你的C应用程序分离了。您可以修复任何错误或扩展其功能,而无需重新编译和重新分发应用程序。

此外,使用存储过程可以是一种安全措施:您可以授予用户对存储过程的执行权限,但对基础表没有更新或插入权限。这可以使您的数据库更安全、更易于管理。

纯粹从函数的角度来看,我想说(几乎)在存储过程中可以做的任何事情都可以通过从linq到sql datacontext执行内联sql来完成,但正如我前面提到的,在这种情况下,您的主应用程序中有所有的sql代码,这可能是一个很好的糟糕的是,这取决于你的应用程序和客户的工作方式和功能。

如果原始速度是 这个 主要关注点,然后使用数据读取器。

否则,linq to sql是一个可靠的替代方案。它提供了强大的命名和类型安全方面的巨大好处。这是一个重大的生产力提升。当您学习如何编写好的linq查询时,特别是学习在适当的地方使用编译查询时,您可以获得非常好的性能。

一个设计良好的基于linq的程序也不会占用内存。是的,数据上下文缓存查询结果,但数据上下文被设计为一个非常短暂的对象。如果将一个数据上下文保存的时间超过一个事务,那么这是错误的。如果在事务结束时处理它们,那么内存损失就消失了。

linq to sql提供了针对sql注入的最佳保护。存储过程应该是最安全的,但这忽略了这样一个事实:太多的人将动态sql放在存储过程中,这否定了参数化调用的所有安全性。linq to sql参数化了所有内容,虽然它对存储过程非常友好,但它不会运行使用动态sql的存储过程。

linq to sql相对于存储过程的一个令人难以置信的优势是,您可以动态地构建查询。

存储过程中构建的许多复杂查询之所以复杂,主要是因为它们是为处理许多可能的情况而构建的。例如,需要构建一个存储过程,该存储过程使用许多可能的参数(其中一些参数是可选的)实现一个过滤器,以适应各种排列,并可能变得非常难看。当然,您可以在linq to sql中构建与一个大型查询相同的查询,但是linqtosql的优点是您不需要。

使用流控制逻辑和查询链,您可以构建一个更简单的查询,该查询只使用搜索中活动的参数,而忽略处理未提供可选参数的情况所需的检查或替代逻辑。使用 Dynamic LINQ 和/或 PredicateBuilders ,这些查询也可以任意复杂,但比存储过程实现的查询还要简单。

要完成与存储过程相同的任务,您必须编写 维护 许多不同的存储过程都在做类似的工作,但不是相同的工作。然后,您必须有相同的流逻辑来选择这些过程。随着参数数量的增加,这一点很快变得不可行。

linq,imo的另一个优点是,它允许开发人员使用更自然的习惯用法(在我的例子中是c)编写查询。虽然我可以编写sql,但编写c代码更为自然。我做得越来越好,越来越快。