为什么 SQL 服务器视图不适合与实体框架一起使用

Question

>我读了这些文章

http://a4academics.com/interview-questions/52-dot-net-interview-questions/973-entity-framework?showall=&start=2

他们说

以下是我们可以考虑提高性能的要点–

如果不需要，请禁用更改跟踪。

使用已编译的 在需要时查询。

避免使用视图

获取所需数据 从数据库。

1(他们试图表达的意思是避免使用视图。

我们可以在数据库中拥有视图，并且可以通过 EDMX 引用。 那么如果我们按 EF 而不是表调用视图会有什么问题呢？

我想知道当我们调用 View by EF 时会发生什么。

谢谢

Answer 1

实际上，视图的唯一问题是它们并不总是包含唯一的候选主键。

视图可以包含类似

ID1 ID2 SomeColumn
==================
1   4          A
1   5          A
1   5          B

其中两个ID列都源自主键表列。

导入到 EDMX 中时，EF 将推断主键，并可能断定{ ID1, ID2 }是一个不错的候选项。如您所见，事实并非如此。在这种情况下，它还应该包括SomeColumn，但在其他情况下，甚至可能没有视图字段的唯一组合！

在实体框架 6 及更早版本中，这导致 EF 实现相同的实体，例如

1 4 A
1 5 A
1 5 A (!)

如您所见，第三行是重复的。

这在开发人员中引起了极大的困惑和许多堆栈溢出问题。只是当视图包含适当的唯一候选键(在 EF 模型中映射为主键(时，在 EF 查询中对只读数据使用视图是完全可以的。

EF6 中不会再修复这个令人困惑的问题，但实体框架核心(从 v2.1 开始(添加了对读取无法识别的视图数据的支持。视图可以读入任何类型，读取视图将简单地返回视图行，而不会因非唯一键而导致重复：没有键。

可以通过以下方式将类型添加到模型中：

modelBuilder.Query<MyViewDto>().ToView("MyView");

。并在 LINQ 查询中使用，如下所示：

db.Query<MyViewDto>().Where(x => x.ID1 == 1)

这将转换为带有WHERE子句的 SQL 查询。