带有实体框架的 ASP.Net Core Web API 使用存储过程有啥好处吗？ [关闭]

Posted 2023-04-12

【中文标题】带有实体框架的 ASP.Net Core Web API 使用存储过程有啥好处吗？ [关闭]

【英文标题】：ASP.Net Core Web API with Entity Framework is there any benefit to using stored procedures? [closed]带有实体框架的 ASP.Net Core Web API 使用存储过程有什么好处吗？ [关闭]

【发布时间】：2021-10-20 08:19:21

【问题描述】：

我有一个 SQL Server 数据库，我通过 ASP.Net Core Web API 使用 Entity Framework 访问该数据库。下面是同一个查询的 2 个示例，其中 1 个使用默认查询方法，第二个使用存储过程。

默认 Web API 查询

     // GET: api/Players
        [HttpGet]
        public async Task<ActionResult<IEnumerable<Player>>> GetPlayers()
        
            return await _context.Players.ToListAsync();
        

使用存储过程

  // GET: api/Players
        [HttpGet]
        public async Task<ActionResult<IEnumerable<Player>>> GetPlayersProc()
        
            string storedProc = "exec GetAllPlayers";
            return await _context.Players.FromSqlRaw(storedProc).ToListAsync();
        

这两个都返回完全相同的玩家列表。

我的问题是使用一种方法比另一种方法有什么好处？是否以任何方式更快或更安全地使用存储过程？这两种方法的优缺点是什么？

【参考方案1】：

SP可以做更多的事情除了返回一个数据集结果，-如果你需要它-可以被认为是一个优势。 相反，在这个简单的情况下，可能没有这样的优势：您花时间创建了一个包含 SQL 代码的 SP，该代码可能与 EF 动态生成的代码非常相似。并且每次更新您的模型时，您必须确保所有 SP 仍然对其正确。

也许更重要的是，SP 可以被授予查询表的访问权限，而此类权限可能会被锁定以进行普通查询，这意味着如果某人（员工或黑客）有权访问具有应用了这样的限制，那么他们就不能随意运行查询，他们只能执行可用的 SP。这仅适用于您和/或 DBA 认为需要这种安全性并且值得花时间和精力去做的情况。您需要为每个查询场景编写一个专用的 SP，使它们与模型更改保持同步，并在每次发布时将它们部署到服务器。需要权衡优势（更好的安全性）和额外的努力。

【讨论】：

那我有一个后续问题。现在我通常必须创建一个服务帐户才能访问数据库，因为个别员工无权访问。如果我使用的是存储过程，我可以绕过使用服务帐户吗？ （我希望这个问题是有道理的，我正确理解你）。

视情况而定。如果您认为用户能够运行任何 SP，那么您可以省略服务帐户。但是，如果您非常注重安全，那么双桶方法（服务帐户可以运行 SP，普通用户什么都不做）可能是最好的。

【参考方案2】：

EF 提供对数据库的强类型访问，因此您可以在编译时检查每个查询。这对性能的影响很小。

当您使用存储过程时，EF 结构和查询之间存在断开连接，如果您的存储过程不正确，那么您可能要到运行时才知道。但是是的，您可以使用 SP 提高性能，但需要付出维护工作的成本。

通常，SP 在 EF 项目中保留用于 SP 预先存在的场景，或者您对 Uber 性能有一些需求，或者正在执行 SQL 引擎已优化支持但难以用 C# 表达的复杂事情。

在由单独的 DBA 团队管理和访问数据库并且您的应用程序代码需要符合他们的控制的情况下，SP 也被大量使用。

在 EF 项目中，SP 通常是一个不必要的抽象层，尤其是当您使用代码优先范式并且还在解决方案中管理架构时。

在您证明合理之前，不要尝试预先优化您的应用程序。为特殊场合保存 SP。

【讨论】：

这非常有用，我确实在使用代码优先方法。那我问你这个。我不久前使用的一本书是使用 Dapper 而不是 EF。我对 Dapper 不是很熟悉，但是将 SP 与 Dapper 一起使用而不是 EF 有什么好处吗？

不管你用什么ORM，参数都是一样的。主要问题是，对于 SP，您需要维护 C# 代码 AND SQL 代码，编译器只能通知您 C# 方面的问题，您需要在使用 SP 的环境中设置适当的回归测试.如果您有一个小型开发团队，请切合实际，仅在绝对必要时才使用 SP。对于一个非常大的团队，您或您的 DBA 可能会喜欢从 SP 那里获得的控制权，但我发现它经常会影响简单的 CRUD 命令的性能提升，而这些命令的执行时间只需不到 10 毫秒。