performance - 实体框架性能问题

我在使用实体框架时遇到了问题。

这是情景。

我有一个名为“Segment”的实体。其中每个都存储在数据库中自己的表中。

“Segments”有一个名为“IsHPMSSegment”的自定义属性，它是一个计算字段。它是通过调用DB中的存储过程来计算的，该存储过程获取“Segment”的“ID”，并将其中一些值与另一个表中的值进行比较。

我们需要运行的其中一个查询说明如下：获取所有HPMS细分的细分。

由于“Segment”的“ISHPMSSegment”值是自定义属性，因此在首次选择段时，我无法直接从DB检索它的值。相反，当在结果集中创建每个“Segment”时，实体框架再次查询db以获取“IsHPMSSegment”的值。因此，每次填充“细分”时，必须再次为每个返回的细分查询数据库。

示例：如果我获得ID大于5的所有“细分”，并且结果集为1000个细分，则数据库总共会被点击1001次。一次获取1000条记录的初始选择查询，然后再填充1000次以填充每个“区段”的“IsHPMSSegment”值。

我能想到的唯一解决方法是在DB（“vSegments”）中创建一个包含此额外计算属性的视图，然后将我的EF对象链接到此视图，而不是链接到“Segment”表。这样，该属性将在第一个查询中填充。

然后，我有两个剩余功能选择（插入，更新，删除）： 1）将实体的插入，更新和删除功能连接到存储过程 2）使视图可更新

所有这些似乎只是为了解决这个性能问题而做了很多额外的工作，我想知道使用EF会有什么好处？

我上面说过的“查看+存储过程”的想法是否有更好的解决方案（仍使用EF）？

如果没有，EF为我提供了哪些好处？如果我从头开始创建自己的DAL，我仍然需要创建存储过程和/或视图。我通过使用EF并且不得不围绕它的限制来节省多少精力？

除此之外，EF似乎无法以令人满意的方式同时更新多个记录。它为您要更新的每条记录发送一个更新语句调用，即使您更新它们完全相同也是如此。这似乎也是一种贬低者（除非有一些我不知道的解决方法）。