使用“缓存”的 LINQ 实体

Question

我遇到了一个问题，我实现了一个使用 LINQ 实体的 WCF 服务...要生成对服务调用的响应内容，需要大量的 LINQ/SQL 选择...

无论如何，该服务没有对​​数据库进行任何更新或插入，所以我想实现一种 LINQ 实体的“缓存”（数据库内容也没有以数百万计增长......它确实会限制在大约 63.000 个主条目（带有子依赖项），例如用户 -> 订单）

此外，服务响应不必包含 100% 的 up2date 数据，因此后台数据的更新不应该在这里考虑

好的，所以目前我的计划如下：

• 使用 LINQ 从数据库中获取所有相关表，以便将所有对象“缓存”（ToList() 函数应该这样做，对吗？）
• 每隔 x 分钟/小时通过一种智能线程替换实体对象（例如再次从 db 中获取数据，锁定当前缓存的 linq-DataContent 并将其替换为新的......）

那么，您的意见是什么...您认为我应该/可以这样做吗？我确实需要增加服务的响应时间，但优化 SQL（例如较少的选择）对我来说并不是一个真正的选择，因为所有 LINQ 的东西都已经实现了..

提前致谢！

Answer 1

对我来说，这听起来像是过早的优化。考虑：

1. 有许多因素会降低这样的应用程序的速度。数据库查询可能根本不是慢的部分。如果慢的部分是 L2E 编译，缓存结果是错误的解决方案。
2. 正确执行缓存失效通常比优化查询更难。当然，也有例外。
3. EF已经在上下文中缓存实体实例。确保您没有重新发明轮子。

换句话说，首先编写正确代码，抽象到可以在必要时插入缓存（存储库模式对此很有用）。对其进行分析，找到慢速部分，然后先修复它们。

Answer 2

我认为您建议的方法是合适的。无论如何，除非您确定始终可以访问相关类中的 all 数据库寄存器，否则我会对其进行修改，以便在启动时检索整个表，而不是在第一次需要时检索寄存器.像这样的：

GetRegister(id)
    if cache has not register with that id
        retrieve register from database
        store register in cache
    return cached register

这样您就实现了缓存，但不会不必要地浪费内存。