最佳实践 - 在 EntityFramework 中混合表实体与视图实体？
我有一个遗留数据库，我想与实体框架进行交互。
该数据库经过高度规范化，用于存储有关航班的信息。为了更容易地处理某些数据，编写了许多 SQL 视图来扁平化数据并将某些多表连接转换为更多逻辑信息。
快速查看后，我发现在 EF 中使用视图有两个问题。
视图包含很多很多键。一些快速谷歌搜索似乎表明我需要手动编辑 EDMX 文件才能删除此信息。
视图与其他表实体没有任何关系。需要手动添加这些关联才能链接视图 ->表。
当 DBA 团队进行更改时，从数据库刷新模型时，这两个似乎都是主要痛点。
这是否只是您在使用 EF 时需要“忍受”的事情，或者是否有任何建议的模式/实践来处理这些问题。
I have a legacy database that I'd like to interact with Entity Framework.
The database is highly normalised for storing information about flights. In order to make it easier to work with some of the data, a number of SQL Views have been written to flatten data and to pivot certain multi-table joins into more logical information.
After quickly looking over this I see two problems with using Views in EF.
The Views contains lots and lots of Keys. Some quick googling seems to indicate I will need to manually edit the EDMX file to remove this info.
The Views don't have any relationships to the other table entities. These associations need to be manually added in order to link a View -> Table.
Both of these seem like major pain points when it comes to refreshing the Model from the DB, when teh DBA team make changes.
Is this just something you need to "put up with" when working with EF or are there any suggested patterns/practices to deal with these.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
将表实体与视图实体混合在一起是可以的，这在很大程度上取决于您的要求。
我的经验是这些是您必须处理的事情。
当我第一次开始使用实体时，我经常使用视图，因为我被告知我需要使用它们。随着我对实体越来越熟悉，我开始更喜欢使用表实体而不是视图实体；主要是因为我觉得我有更多的控制权。当您呈现只读信息或如您所描述的那样（展平数据、枢轴、连接等）时，视图是可以的；然而，当您的需求发生变化并且您现在必须添加 CRUD 时，您将不得不使用存储过程或更改模型以使用表实体，因此您最好从一开始就使用表实体。
这对我来说从来都不是真正的问题。您可以在设计器中撤消视图实体的键。如果您谈论的是对存储层中的视图执行此操作，那么是的，您可以使其工作，但是一旦您从数据库更新模型，您将不得不再次执行此操作 - 我不建议这样做。您最好与 DBA 一起调整数据库中的关键约束。
这对我来说经常是一个问题。有时您可以毫无问题地添加键并创建关系，但很多时候您可能必须更改键和/或关系在数据库中使其工作——这取决于您的要求；即使使用表实体，您也可能必须处理这个问题。
希望这有帮助。
Mixing Table-Entities with View-Entities is ok and largely depends on your requirements.
My experience has been these are things you are going to have to deal with.
When I first started using Entity, I used views a lot because I was told I needed to use them. As I became more familiar with Entity I began to prefer the use of table-entities over view-entities; mainly because I felt I had more control. Views are ok when you are presenting read-only info, or as you described (flattend data, pivots, joins etc.); however, when your requirements change and you now have to add CRUD, you are going to have to use stored procedures or change your model to use table-entites anyway, so you might as well use table-entities from the start.
This wasn't ever really a problem for me. You can undo keys of the view-entity in the designer. If your talking about doing this for the view in the storage layer, then yes, you can, to make it work, but as soon as you update your model from the database, you are going to have to do this over again -- I wouldn't recommend doing this. You are better off working with your DBA to adjust the key constraints in the database.
This was often a problem for me. Sometimes you are able to add keys and create relationships without any problems, but often times you may have to change the keys and/or relationships in the db to make it work -- this depends on your requirements; you may have to deal with this even when using table-entities.
Hope this helps.
当我们转向使用实体框架时，我也遇到过类似的情况。
第一步是从空白 EF 模型开始，并在创建域服务调用时添加表。这至少意味着这个模型一开始并不疯狂！然后计划是尝试尽可能不使用视图，并将这种逻辑移至域服务中，至少可以对其进行测试，并慢慢弃用 CRUD 存储过程。它运行得很好，并没有真正出现任何重大问题。
在实践中，仍然存在一些视图，主要用于需要高性能的情况，幸运的是，这些视图可以被单独考虑（对于只读网格），并且已保留在模型中，没有关联。添加钥匙我肯定会很烦人。
编辑 EDMX 文件是可以的，但有时在模型刷新时这些更改可能会丢失。这种情况发生在我身上，特别是当 EF 认为表是一个视图时。是的，这是一种痛苦，而且是刚刚忍受的事情。
I've been in a similar situation as we transitioned into using Entity Framework.
The first step was to start with a blank EF model and add the tables when we created the domain service calls. This at least meant that the model wasn't crazy to start with! Then the plan was to try and not use views as much as possible and move that kind of logic into the domain service, where at least it could be tested, and slowly deprecate the CRUD stored procedures. It's worked fine and there haven't really been any major problems.
In practice there are still some views, mainly used for situations that need to be performant, Fortunately these views can be considered in isolation (for read only grids) and have been left as such in the model with no associations. Adding the keys in would I'm sure be annoying.
Editing the EDMX file is okay, but sometimes on a model refresh these changes can get lost. This has happened to me particularly when EF thinks a table is a view. And yes it's a pain and something that has just been put up with.