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

Question

我有一个 SQL Server 数据库，我正在使用实体框架通过 ASP.Net Core Web API 访问该数据库。以下是同一查询的 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

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

当您使用存储过程时，EF 结构和查询之间存在脱节，如果您的存储过程不正确，那么您可能要到运行时才能知道。但是，是的，您可以通过 SP 提高性能，但这会增加维护工作量。

一般来说，EF项目中会保留SP，用于SP已经存在的场景，或者你对Uber性能有一些需求，或者正在做一些复杂的事情，SQL引擎已经优化了支持，但很难用C#表达。

SP 也经常被使用，其中一个单独的 DBA 团队管理数据库并访问数据库，并且您的应用程序代码需要符合他们的控制。

SP 通常是 EF 项目中不必要的抽象层，特别是如果您使用代码优先范例并且也在解决方案中管理架构。

在证明其合理性之前，不要尝试预先优化您的应用程序。为特殊场合保存 SP（将 SP 视为特殊程序），或者在您的解决方案或部分解决方案成熟并且您拥有完善的测试或 QC 制度后进行优化。

Answer 2

SP 除了返回数据集结果之外，还可以做更多事情，这 - 如果您需要它 - 可以被视为一个优势。
在这个简单的例子中，可能没有这样的优势，相反：您花时间创建一个包含 SQL 代码的 SP，该代码可能与 EF 即时生成的代码非常相似。每次更新模型时，您都必须确保所有 SP 仍然正确。

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