EF Core中用CustomView接收存储过程返回值的执行逻辑与性能疑问

关于EF调用逻辑的理解 #

你的理解是错误的。当你执行await dbContext.CustomView.FromSqlRaw("EXEC [dbo].[MySproc] @param1, @param2 etc.")时：

• EF 不会执行CustomView对应的SQL视图逻辑，它完全忽略了这个实体关联的视图定义。
• 实际流程是：直接执行你指定的存储过程MySproc，然后把存储过程返回的结果集直接映射到CustomView实体对象上。这里的CustomView只是作为一个数据接收容器存在，和它对应的SQL视图没有任何执行层面的关联。

关于性能问题的疑惑 #

用CustomView（对应SQL视图的实体）代替DTO，本身不会带来额外的性能开销，但要注意潜在的风险：

• 映射阶段无差异：EF把存储过程结果映射到CustomView和映射到普通DTO的逻辑完全一致，都是基于列名匹配实例化对象，耗时几乎可以忽略。
• 需警惕导航属性触发额外查询：如果CustomView实体上定义了导航属性、启用了延迟加载，后续代码若不小心访问这些未被存储过程填充的导航属性，EF会自动触发额外的数据库查询（也就是常见的N+1性能问题）。而DTO通常不会包含这些EF关联配置，所以更安全。
• 实体冗余配置无性能影响：即便CustomView上有索引、数据验证等EF注解，这些在结果映射阶段也不会产生性能损耗，只是属于冗余配置而已。

内容的提问来源于stack exchange，提问作者mint