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

Question

我有一个 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();
        }

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

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