实体框架查找与哪里 [英] Entity Framework Find vs. Where

问题描述

.Find（id）和之间有显着差异。（x => x.Id == id） code>应该强迫我使用 .Find（）超过$ code> .Where（）/。First（）？

我想象， .Find（）会更有效率，但是效率要高得多我应该避免 .Where（）/。First（）？

我问的原因是我正在使用在我的测试中，通用的FakeDbSet使得它很容易实现假的结果，到目前为止，我发现我必须继承该类并提供 .Find（）的自定义实现，而如果我用编写我的代码.Where（）/。First（）我不需要做这个额外的工作。

解决方案

重点在于， find 通过搜索上下文的本地缓存开始，然后如果没有匹配，则发送对db的查询。

其中总是向db发送查询。

与EF 4. * ，我以前认为由 find 生成的sql太复杂了，在某些情况下会导致性能问题。所以我总是使用其中甚至使用EF 5.我应该检查由$ 5生成的s $ c找到与EF 5。 p>

所以在本文中， find 更好，因为他使用缓存。

Is there a significant difference between .Find(id) and .Where(x = >x.Id == id) that should compel me to use .Find() over .Where()/.First()?

I would imagine that .Find() would be more efficient but is it so much more efficient that I should avoid .Where()/.First()?

The reason I ask is that I am using a generic FakeDbSet in my tests to make it easy to implement fake results and so far I have found that I must inherit that class and provide a custom implementation of .Find() whereas if I write my code with .Where()/.First() I don't need to do that extra work.

解决方案

The point is that find starts by searching in the local cache of the context and then, if no match, sends a query to the db.

where always sends a query to the db.

With EF 4.*, I used to think that sql generated by find was too complex and, in some cases, leads to a performance issue. So I always use where even with EF 5. I should check the sql generated by find with EF 5.

So in the paper, find is better because he uses the cache.

这篇关于实体框架查找与哪里的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！