最佳实践 - 将表实体与实体框架中的视图实体混合使用？

Question

我有一个遗留数据库，我想与Entity Framework进行交互。

数据库高度标准化，用于存储有关航班的信息。为了更容易使用某些数据，已经编写了许多SQL视图来展平数据并将某些多表连接转换为更多逻辑信息。

快速查看后，我发现在EF中使用视图存在两个问题。

1. 视图包含大量密钥。一些快速谷歌搜索似乎表明我将需要手动编辑EDMX文件以删除此信息。

2. 视图与其他表实体没有任何关系。需要手动添加这些关联才能链接视图 - ＆gt;表

当DBA团队进行更改时，从DB中刷新模型时，这些似乎都是主要的痛点。

这是您在使用EF时需要“忍受”的东西，还是有任何建议的模式/做法来处理这些问题。

Answer 1

将表 - 实体与View-Entities混合即可，主要取决于您的要求。

我的经验是这些是你必须要处理的事情。

当我第一次开始使用Entity时，我使用了很多视图，因为有人告诉我需要使用它们。随着我越来越熟悉实体，我开始更喜欢在视图实体上使用表实体;主要是因为我觉得我有更多的控制权。当您呈现只读信息时，或者如您所述（平面数据，枢轴，连接等），视图都可以。但是，当您的需求发生变化并且您现在必须添加CRUD时，您将不得不使用存储过程或更改模型以使用table-entites，因此您不妨从一开始就使用表实体。

  

视图包含许多键。一些快速的谷歌搜索似乎   表示我需要手动编辑EDMX文件以删除它   资讯

这对我来说并不是真正的问题。您可以在设计器中撤消视图实体的键。如果您正在讨论为存储层中的视图执行此操作，那么是的，您可以使其工作，但是一旦从数据库更新模型，您将不得不重新执行此操作 - 我不建议这样做。最好使用DBA来调整数据库中的关键约束。

  

视图与其他表实体没有任何关系。   需要手动添加这些关联才能链接视图    - ＆GT;表

这对我来说经常是个问题。有时您可以添加密钥并创建关系而不会出现任何问题，但有时您可能需要更改密钥和/或数据库中的关系使其工作 - 这取决于您的要求;即使使用表格实体，也可能必须处理这个问题。

希望这有帮助。

Answer 2

我们过渡到使用Entity Framework时情况类似。

第一步是从空白EF模型开始，并在创建域服务调用时添加表。这至少意味着该模型开始时并不疯狂！然后计划尝试尽可能不使用视图并将这种逻辑移动到域服务中，至少可以对其进行测试，并慢慢弃用CRUD存储过程。它运作良好，并且确实存在任何重大问题。

在实践中仍然存在一些视图，主要用于需要高效的情况。幸运的是，这些视图可以单独考虑（对于只读网格），并且在模型中没有关联。添加密钥我肯定会很烦人。

编辑EDMX文件是可以的，但有时在模型刷新时这些更改可能会丢失。特别是当EF 认为表是视图时，这种情况发生在我身上。是的，它是一种痛苦和刚刚忍受的东西。