我有一个想要与 Entity Framework 交互的旧数据库。
数据库高度规范化以存储有关航班的信息。为了更轻松地处理某些数据，我们编写了许多 SQL 视图来展平数据并将某些多表连接转换为更多逻辑信息。
在快速查看后，我发现在 EF 中使用视图有两个问题。
视图包含很多很多的键。一些快速的谷歌搜索似乎表明我需要手动编辑 EDMX 文件以删除此信息。
视图与其他表实体没有任何关系。需要手动添加这些关联才能链接视图 -> 表格。
当 DBA 团队进行更改时，从数据库中刷新模型时，这两个似乎都是主要的痛点。
这只是您在使用 EF 时需要“忍受”的事情，还是有任何建议的模式/实践来处理这些问题。
【问题讨论】：
标签： c# entity-framework view edmx
在我们过渡到使用实体框架时，我也遇到过类似的情况。
第一步是从一个空白 EF 模型开始，并在我们创建域服务调用时添加表。这至少意味着该模型一开始并不疯狂！然后计划是尽量不使用视图，并将这种逻辑移动到域服务中，至少可以对其进行测试，然后慢慢弃用 CRUD 存储过程。它运行良好，并没有真正出现任何重大问题。
实际上仍然有一些视图，主要用于需要高性能的情况，幸运的是，这些视图可以单独考虑（对于只读网格），并且在模型中保持原样，没有关联。添加密钥会很烦人。
编辑 EDMX 文件没问题，但有时在模型刷新时这些更改可能会丢失。这发生在我身上，尤其是当 EF 认为 一个表是一个视图时。是的，这是一种痛苦，而且是刚刚忍受的。
【讨论】：
将 Table-Entities 与 View-Entities 混合是可以的，很大程度上取决于您的要求。
我的经验是这些都是你必须处理的事情。
当我第一次开始使用 Entity 时，我经常使用视图，因为有人告诉我我需要使用它们。随着我对实体越来越熟悉，我开始更喜欢使用表实体而不是视图实体；主要是因为我觉得我有更多的控制权。当您呈现只读信息或如您所描述的（展平数据、枢轴、连接等）时，视图是可以的；但是，当您的需求发生变化并且您现在必须添加 CRUD 时，您将不得不使用存储过程或更改您的模型以使用表实体，因此您最好从一开始就使用表实体。
视图包含很多很多的键。一些快速的谷歌搜索似乎 表示我需要手动编辑 EDMX 文件以删除它 信息。
这对我来说从来都不是问题。您可以在设计器中撤消视图实体的键。如果您谈论为存储层中的视图执行此操作，那么是的，您可以使其工作，但是一旦您从数据库更新模型，您将不得不再次执行此操作 - 我不建议这样做。您最好与您的 DBA 一起调整数据库中的关键约束。
视图与其他表实体没有任何关系。 需要手动添加这些关联才能链接视图 -> 表格。
这经常对我来说是个问题。有时您可以毫无问题地添加键和创建关系，但通常您可能不得不更改键和/或数据库中的关系以使其工作 - 这取决于您的要求；即使使用表实体，您也可能必须处理这个问题。
希望这会有所帮助。
【讨论】：