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