Dilemma di progettazione a livello aziendale: memoria o io?

Question

Il progetto su cui sto lavorando sta affrontando un dilemma di progettazione su come ottenere oggetti e raccolte di oggetti da un database. A volte è utile tampone *tutto* Oggetti dal database con le sue proprietà in memoria, a volte è utile impostare un ID oggetto e interrogare le sue proprietà su richiesta (chiamata 1 dB per oggetto per ottenere tutte le proprietà). E in molti casi, le raccolte devono supportare entrambi gli oggetti di buffering in memoria e inizializzati con informazioni minime per l'accesso su richiesta. Dopotutto, non tutto può essere tamponato in memoria e non tutto può essere letto su richiesta. È una memoria onnipresente vs IO problema.

Qualcuno ha dovuto affrontare lo stesso problema? In che modo ha influenzato il tuo design? Quali sono le lezioni difficili imparate? Altri pensieri e consigli?

MODIFICARE: Il mio progetto è un classico esempio di DLL a livello aziendale, consumato da un'applicazione Web, servizi Web e applicazione desktop. Quando è richiesto un elenco di prodotti per un'applicazione desktop e visualizzato solo con il nome del prodotto, è OK avere questa sequenza di passaggi per visualizzare tutti i prodotti (diciamo che ci sono un milione di prodotti nel database):
1. Una chiamata DB per ottenere tutti i nomi dei prodotti
2. Una chiamata DB per ottenere tutte le informazioni sul prodotto se l'utente fa clic sul prodotto per visualizzare i dettagli (accesso su richiesta)

Tuttavia, se questa stessa API sarà consumata da un servizio Web per visualizzare tutti i prodotti con dettagli, il traffico di rete diventerà loquace. La sequenza migliore in questo caso sarebbe:
1. Che diamine, buffer tutti i prodotti e i campi di prodotto da una sola chiamata DB (in questo caso buffering 1 milione di prodotti sembrano anche spaventosi)