Linq 与存储过程答案

【问题标题】：Linq vs Stored ProcedureLinq 与存储过程
【发布时间】：2010-04-28 08:35:03
【问题描述】：

哪一个更适合企业 CMS 开发： LINQ 还是 SP？

【问题讨论】：

【解决方案1】：

通常我所做的是 LINQ to Views 和 LINQ to Stored Procedures。这不是首选什么的问题，因为 LINQ 解决了如何在查询存储过程在 SQL 端运行的位置后如何管理数据，以允许对数据进行查询操作（或者对我来说，主要是保存），从而避免使用代码这样做比较慢。

如果有必要，我会说你会想要同时使用这两个。您是否保存到需要多个表保存为一个实体的实体？如果是这样，请使用带有 LINQ 的存储过程。如果您对表使用 1 对 1 实体关系，则只需使用 LINQ。

【讨论】：

【解决方案2】：

存储过程可以与 Linq2Sql（和实体框架）一起使用，所以它不是一个或另一个的选择。

【讨论】：

【解决方案3】：

我会为 CMS 缓存数据库中的结果，因为您可能会一遍又一遍地获得相同的数据请求（缓存数据集，或使用页面缓存，或者如果使用 LINQ，则缓存对象）。

那么你使用 LINQ 还是 SP 都没有关系，但我只会使用 LINQ。

【讨论】：

【解决方案4】：

对于简单的 CRUD 表（没有连接！！！）操作 LINQ to SQL 很好，但是对于更复杂的东西（需要连接）我总是使用存储过程（如果你愿意，你可以使用 Linq 到存储过程）

在这个网站和其他网站上有很多关于这个的辩论。对我来说，你通常可以将 pro Linq 阵营分成最近接触编程并且没有使用存储过程的历史的人，即没有大量参与以前项目的数据库方面。

根据我使用纯 LINQ、存储过程和这两者的混合处理多个项目的经验，我坚持使用 Linq 进行基本 CRUD 和存储过程用于更复杂或依赖性能的任何事情。

1 - 部署/安全 - 任何在现实世界中工作过的人都非常清楚，将数据库逻辑分离到存储过程中而不是合并到源代码和发布的 DLL 中是一个巨大的优势。您可以使用角色和 SQL 服务器安全性在每个查询周围添加适当的安全/访问层，这对于任何严肃的企业级公司来说都是必不可少的，您还可以更改任何存储过程的 SQL，而无需发布新的主要版本应用程序（dll）。我不在乎你声称自己有多好，我们都必须使用存储过程来解决实时问题和性能瓶颈，而必须使用新的应用程序版本来解决这个问题将是一场噩梦。

2 - 性能/代码异味 - 我看到很多应用程序都充斥着大量写得不好且效率低下的 Linq。开发人员对 Linq 变得懒惰，几乎没有隐藏的懒惰 Linq to SQL 查询，这会让您在尝试调试企业级系统上的性能问题时做噩梦——“尽快完成”的座右铭似乎很普遍。自从 Linq 出现以来，我看到的意大利面条代码比微软自 COM 以来发布的任何以前的类库/模式中看到的都要多。

【讨论】：