c# - 业务层设计困境 : memory or IO?

Question

我正在从事的项目面临着如何从数据库中获取对象和对象集合的设计困境。有时将数据库中的 *all* 对象及其属性缓冲到内存中很有用，有时仅设置对象 ID 并按需查询其属性很有用(每个对象 1 db 调用以获取所有属性)。在许多情况下，集合需要支持将对象缓冲到内存中并使用最少的信息进行初始化以供按需访问。毕竟，不是所有的东西都可以缓冲到内存中，也不是所有的东西都可以按需读取。这是一个普遍存在的内存 vs IO 问题。

有人遇到过同样的问题吗？对您的设计有何影响？有哪些惨痛的教训？还有其他想法和建议吗？

编辑:我的项目是业务层 dll 的典型示例，由 Web 应用程序、Web 服务和桌面应用程序使用。当为桌面应用程序请求产品列表并且仅按产品名称显示时，可以按以下步骤顺序显示所有产品(假设数据库中有一百万个产品):
1. 一次数据库调用获取所有产品名称
2.如果用户点击商品查看详情，一次db调用获取所有商品信息(按需访问)

但是，如果 Web 服务要使用同一个 API 来显示所有产品的详细信息，网络流量就会变得很嘈杂。在这种情况下更好的顺序是:
1. 搞什么，从一个数据库调用中缓冲所有产品和产品字段(在这种情况下缓冲 100 万个产品看起来也很可怕)

Answer 1

这取决于数据更改的频率。缓存静态和近静态数据(通常带有缓存过期窗口)是很常见的。

数据库已经被设计成缓存数据，所以只要网络 I/O 不是瓶颈，就让数据库做它擅长的事。

您是否看过一些可用的缓存技术？

• .NET Framework 4 ObjectCache Class

• Cache Class : Using the ASP.NET Cache outside of ASP.NET

• Velocity: Build Better Data-Driven Apps With Distributed Caching

• Object cache for C#