Dilema de diseño de la capa de negocios: ¿Memoria o IO?

Question

El proyecto en el que estoy trabajando se enfrenta a un dilema de diseño sobre cómo obtener objetos y colecciones de objetos de una base de datos. A veces es útil para amortiguar *todos* Objetos de la base de datos con sus propiedades en la memoria, a veces es útil establecer una ID de objeto y consultar sus propiedades a pedido (1 dB de llamada por objeto para obtener todas las propiedades). Y en muchos casos, las colecciones deben admitir ambos objetos de almacenamiento en búfer en la memoria y ser inicializados con información mínima para el acceso a pedido. Después de todo, no todo se puede almacenar en la memoria y no todo se puede leer a pedido. Es un problema de memoria ubicua frente a IO.

¿Alguien tenía que enfrentar el mismo problema? ¿Cómo afectó su diseño? ¿Cuáles son las lecciones difíciles aprendidas? ¿Alguna otra idea y recomendación?

EDITAR: Mi proyecto es un ejemplo clásico de una DLL de capa comercial, consumida por una aplicación web, servicios web y aplicación de escritorio. Cuando se solicita una lista de productos para una aplicación de escritorio y se muestra solo por nombre del producto, está bien tener esta secuencia de pasos para mostrar todos los productos (digamos que hay un millón de productos en la base de datos):
1. Una llamada de DB para obtener todos los nombres de productos
2. Una llamada de DB para obtener toda la información del producto si el usuario hace clic en el producto para ver los detalles (acceso a pedido)

Sin embargo, si esta misma API será consumida por un servicio web para mostrar todos los productos con detalles, el tráfico de la red se volverá conversador. La mejor secuencia en este caso sería:
1. ¿Qué diablos, amortigua todos los productos y campos de productos de una sola llamada de DB (en este caso, amortiguando 1 millón de productos también parece aterrador)?