questi sono tutti molto soggettiva e dipende dal tipo di sito che avete, ma qui sono i miei due centesimi:
messaggi UI - se multilingue, memorizzarli in file di risorse
numero di record utilizzati nella paginazione & altri parametri dell'interfaccia utente - mi piace fare questa selezionabili dagli utenti, se si utilizza jQuery per fare questo plugin come tablesorter e tablesorter.pager rendere più facile
Durata della cache per le pagine Web & timeout - dipende realmente dalla tempistica dei dati. Se il contenuto viene aggiornato di frequente, è possibile che non si desideri memorizzarlo a lungo. Ma se c'è un sacco di codice per recuperare e organizzare i dati, potresti volerlo conservare più a lungo per migliorare le prestazioni.
percorso mappe & struttura del sito - davvero dipende da che tipo di sito che avete e se andrà a beneficio degli utenti
AppSettings (web.config) - buoni per le costanti e gli elementi che non si cambiare spesso, o sono specifici per tale impianto, come ad esempio URL di base, webservice url, chiavi API di Google, ecc
sezioni personalizzate (web.config) - può essere buono per le impostazioni che non sono conformi al bene formato dizionario, una chiave per un valore.
File xml/testo esterni riferiti al web.config - Lo uso come ultima risorsa, potrebbe essere preferibile, ma odio usare il file i/o sul sito.
classe interna statica (es) di costanti - buon approccio per memorizzare le impostazioni che vengono caricati dal db, per evitare un'ogni db successo sono necessari i valori
tabella del database (s) - quando usando le tabelle db per le impostazioni, preferisco caricarle in una classe statica e aggiornarla periodicamente, per evitare di dover colpire il db ogni volta che ho bisogno dei dati
ok :) Le chiederò alcune domande dettagliate separatamente –
wrt to 2 ultimi punti, la cache con opzione di callback sarebbe migliore (che statica)? – PRR