假设我向数据库发送一个查询并获得 1000 个对象，如果我使用同一个对象再次发送此查询DbContext，那么我将从本地存储中获取这些对象。而如果，在处理另一个asp.net请求时，应用程序同时或相差很小（例如0.5秒）向数据库发送相同的sql查询，是否应该再次联系数据库？
我有一张很少更新的表，可以完全放入 RAM 中而不会出现任何问题。是否可以缓存它并仅更新它，例如每 24 小时？（我的意思是通过框架，而不是服务中的静态集合）
RError.com
实体框架不支持这种情况。在 EF 6 之前的版本中，如果其中出现大量对象，它会显着减慢速度
DbContext，因此使用它的标准方案是短生命周期。在 Web 应用程序中，使生命周期与 Web 请求的生命周期相同是最方便的，在这种情况下，作为处理请求的一部分执行的所有操作都包含在事务中。通常，这正是所需要的。
至于缓存，在没有性能测试的情况下解决这个问题很可能是过早的优化。如果表很小并且很少更改，SQL Server 本身将缓存它就好了。首先，它可能会适合一页数据（8KB），SQL Server 会在一个磁盘访问中加载它；其次，如果是定期请求，它只会在 SQL Server 缓存中；第三，如果没有人写它，就不会有锁。
如果将来需要缓存，可以使用方面编程工具添加它：为存储库开发缓存装饰器。这些装饰器可以检查数据是否在缓存中。如果它们不存在，装饰器会从数据库中请求数据并将其放入缓存中。通过在强大的 IoC 容器中实现拦截器的概念，这些装饰器可以非常容易地开发。