Menu di progettazione Visualizzazione di più categorie

0

Sto cercando aiuto per progettare il codice per creare un menu che mostri più categorie. Attualmente, il codice (classico asp) effettua una chiamata al database e quindi scorre i risultati, quindi è tutto in linea. Sto effettuando il porting del codice su MVC 5 / C #. Quello che sto facendo ora è ottenere tutte le categorie dal database, passandole alla vista, e poi per ogni categoria faccio scorrere i risultati per creare le voci del menu. Questo non sembra il piano peggiore, ma ha l'odore del codice di dover eseguire una query linq per ogni categoria nella vista del rasoio. Quindi spero che qualcuno là fuori possa avere un'idea migliore o mi faccia sapere se questa è un'opzione accettabile. Solo per aggiungere alla conversazione, ecco le opzioni che attualmente penso che io possa scegliere.

Opzione 1: crea un ViewModel con tutte le categorie già separate. In questo caso, gestirò tutto l'ordinamento nel controller e quindi tutta la vista farebbe iterare i risultati. Il richiamo alla mia mente è che qualsiasi modifica alla struttura del menu mi obbliga a cambiare il modello di visualizzazione, quindi devo aggiornare i file sul server.

Opzione 2 (una che sto usando ora) - Imposta l'elenco delle categorie come modello per la vista e nel codice del rasoio, lascia filtrare le categorie di cui ho bisogno per il particolare gruppo di menu e quindi scorrere su di esse per creare il voci del menu. Questo mi dà più flessibilità, dal momento che posso cambiare la vista senza dover ricompilare il codice. Lo svantaggio consiste nel dover eseguire query linq nel codice.

Se qualcuno può pensare ad altre valide opzioni, gradirei l'aiuto.

    
posta Wade73 13.12.2016 - 16:35
fonte

1 risposta

1

Mi sembra una micro-ottimizzazione per me.

Se non diversamente dimostrato da test rigorosi, le micro-ottimizzazioni sono spesso una perdita di tempo. Potresti risparmiare alcuni millisecondi dal tuo tempo di esecuzione, ma il costo è un codice che è più difficile da leggere e più difficile da mantenere.

Devi bilanciare il tempo risparmiato nell'esecuzione con il tempo aggiuntivo richiesto agli sviluppatori per mantenere il codice.

Vado con il codice più semplice e facile da capire possibile. Sembra l'opzione 2 con le query di linq.

Se vuoi sentirti meglio, prova a utilizzare System.Diagnostics.Stopwatch per vedere quanta parte della query su linq ti costa. Sarei sorpreso se si tratta di oltre 200 millisecondi.

    
risposta data 13.12.2016 - 18:46
fonte

Leggi altre domande sui tag