c# – 业务层设计困境：内存还是IO？

我正在研究的项目面临着如何从数据库中获取对象和对象集合的设计困境.有时将来自数据库的* all *对象及其属性缓冲到内存中是有用的,有时仅设置对象id并按需查询其属性(每个对象1 db调用以获取所有属性)是有用的.在许...

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

有没有人必须面对同样的问题？怎么影响你的设计？有什么艰难的教训？还有其他想法和建议吗？

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

但是,如果Web服务将使用相同的API来显示包含详细信息的所有产品,则网络流量将变得很繁琐.在这种情况下,更好的顺序是：
1.什么,只缓冲一个数据库调用缓冲所有产品和产品领域(在这种情况下缓冲100万产品看起来也很可怕)

解决方法:

这取决于数据变化的频率.缓存静态和近静态数据(通常具有缓存到期窗口)是很常见的.

数据库已经设计用于缓存数据,因此如果网络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#