实体框架 - 视图与表答案

【问题标题】：Entity Framework - Views vs Tables实体框架 - 视图与表
【发布时间】：2015-04-26 13:33:36
【问题描述】：

我在我的 ASP.NET MVC 项目中使用 Entity Framework 6，使用数据库优先方法....我有一个包含所有表关联的 .edmx 文件。

现在，sql 开发人员不想直接调用表，所以他们希望我使用视图来代替。

我想了解使用视图与表格有什么好处？

另外，如果我使用 Views 并在 edmx 中应用所有 PK 和 FK 并重新生成某些内容，这些更改会丢失吗？

请问有什么想法吗？

【问题讨论】：

这里的好处/权衡将是广泛的，这实际上取决于您需要什么以及您要去哪里。我猜你不允许自己写任何观点？如果是这样，那么您可能根本无法按预期使用 EF...
我可以创建视图，但他们更喜欢直接使用视图而不是表。我仍然可以将 ef 与视图一起使用，不是吗？
比较麻烦。 EF 中的视图支持很差。
项目已经在 EF 中 - 没有办法。
数据库开发人员不能向您（或他们自己）解释这些好处吗？这听起来像是不必要的僵化，如果不是地盘争夺战的话。

标签： c# asp.net asp.net-mvc entity-framework

【解决方案1】：

您的 SQL 开发人员是白痴。请随时告诉他们。与直接使用表相比，使用表视图唯一能做的就是禁止写操作。如果这是目标，还有更好的方法来实现这一目标，方法很简单，比如让应用程序使用没有写入权限的用户。

通过使用视图，您放弃了主键、外键和索引，所有这些都有助于提高查询的性能。换句话说，您的 SQL 开发人员要求您更加努力地访问数据库并对其进行性能较低的查询。换句话说，他们不知道自己在说什么。

如果应用程序需要写入（坦率地说，很少有应用程序不需要），那么无论如何视图都会出现。如果他们真的很关心 Entity Framework 进行写入，那么他们还可以为 CREATE、UPDATE 等任务创建存储过程，您可以将这些存储过程集成到 Entity Framework 中。但是，我几乎可以向您保证，Entity Framework 生成的 SQL 比他们手工编写的更好，如果没有其他原因，它被使用和贡献的人远远多于您的员工。

【讨论】：

并不是说我同意那些 SQL 开发人员，我不同意，但是有 msdn.microsoft.com/en-us/library/ms191432.aspx 和这个 msdn.microsoft.com/en-us/library/ms180800.aspx 简单的问题是视图在 EF 中没有得到很好的支持。
哎呀，这是一个严厉的说法。我可以这么说。视图不依赖于表结构有什么好处吗？这意味着如果表结构发生变化我们不依赖？
参数在这里：stackoverflow.com/questions/4378068/…
这些观点不错，但我坚持我的观点。我从未见过使用无法以更好和更高性能的方式解决的视图的良好实用理由，尤其是在谈论理想情况下应该处理 1000 多个同时请求的网站之类的东西时（无论如何，这就是梦想）。也许如果您将它用于报告或其他一些内部的、低容量的任务，那么在某处可能存在使用视图的争论。否则，我看不到它。
如果你在做搜索，尤其是有 50+ 百万个数据点，你应该使用真正的搜索引擎，而不是查询数据库。研究类似 Elasticsearch 的东西。它是目前最好的之一，并且通过 NEST Nuget 包有一个 C# 客户端。它甚至是 StackExchange 网络所使用的。