.net 如何使用实体框架处理查找表/数据？

今天，我创建代理实体来从内存加载查找数据

我建议，实体框架应该足够聪明，不会生成连接到国家/地区的表

DbContext.Users.Include(u => u.Country.Select(c => c.Place))

相反，EF应该从内存中获取数据

---

您是如何使用实体框架处理查找数据的？

因此您希望EF在访问之前将所有查找表加载到内存中？这听起来有点凌乱和粗暴。（如果查找有更新怎么办？您将如何同步？）如果使用Pks，则可以快速连接到查找表。如果需要在内存中加载查找表，仍然需要在linq查询中连接到保存表数据的代理对象。我没有硬数据，但我看不出这两种技术在性能上有多大差异。如果有什么区别的话，Linq示例可能会慢一些

---

我的经验法则是：如果两种技术在速度和回报方面相似，那么就选择一种不太复杂且易于维护的技术（在您的情况下，使用Include（））。

您的问题是什么？如果查找表很小，很可能它已经从RDBMS端的内存中获取。过早优化通常不是一件好事，所以微软决定不参与其中。谢谢你的回答！我认为，在我的例子中，从缓存（键/值字典）加载国家和地区甚至州的代理对象应该比连接（除了linq到实体sql生成）更快。我认为每次从DB加载数据都是荒谬的（这个表在运行时永远不会更新）。nhibernate的二级缓存还可以工作吗？如果它们永远不会在运行时更新，我看不出缓存表有什么大问题。但是，我不希望您看到非常大的性能提升（如果有的话）。编写一个快速的实验控制台应用程序来测量这两种技术的性能。一个总是转到数据库进行连接，另一个缓存开始，然后运行一组连接。对其中一个进行10000次迭代，看看性能提升是否足以进行架构更改。记住——过早优化是万恶之源。