时间戳

首页 > 解决方案 > 带有实体框架的 ASP.Net Core Web API 使用存储过程有什么好处吗？

c# - 带有实体框架的 ASP.Net Core Web API 使用存储过程有什么好处吗？

问题描述

我有一个 SQL Server 数据库，我正在使用 Entity Framework 使用 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();
        }

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

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

标签： c#sql-serverasp.net-web-apistored-procedures

解决方案

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

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

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

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

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

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

推荐阅读