Dilemme de conception de couche commerciale: mémoire ou IO?

Question

Le projet sur lequel je travaille est confronté à un dilemme de conception sur la façon d'obtenir des objets et des collections d'objets à partir d'une base de données. Parfois, il est utile de tamponner *tout* Des objets de la base de données avec ses propriétés en mémoire, il est parfois utile de simplement définir un ID d'objet et de remettre en question ses propriétés à la demande (1 dB d'appel par objet pour obtenir toutes les propriétés). Et dans de nombreux cas, les collections doivent prendre en charge les deux objets tampon en mémoire et être initialisés avec un minimum d'informations pour l'accès à la demande. Après tout, tout ne peut pas être tamponné en mémoire et tout ne peut pas être lu à la demande. C'est un problème de mémoire omniprésente vs IO.

Quelqu'un a-t-il dû faire face au même problème? Comment a affecté votre conception? Quels sont les leçons difficiles apprises? D'autres pensées et recommandations?

ÉDITER: Mon projet est un exemple classique d'une DLL de couche commerciale, consommée par une application Web, des services Web et une application de bureau. Lorsqu'une liste de produits est demandée pour une application de bureau et affichée uniquement par nom de produit, il est acceptable d'avoir cette séquence d'étapes pour afficher tous les produits (disons qu'il y a un million de produits dans la base de données):
1. Un appel de base de données pour obtenir tous les noms de produits
2. Un appel de base de données pour obtenir toutes les informations du produit si l'utilisateur clique sur le produit pour voir les détails (accès à la demande)

Cependant, si cette même API va être consommée par un service Web pour afficher tous les produits avec des détails, le trafic réseau deviendra bavard. La meilleure séquence dans ce cas serait:
1. Ce que diable, tamponnez tous les produits et champs de produits à partir d'un seul appel de base de données (dans ce cas, tamponner 1 million de produits semblent également effrayants)