MVC: modelli completamente popolati o modelli parzialmente riempiti?

Question

MVC: modelli completamente popolati o modelli parzialmente riempiti?

#1 da (3 voti)
#2 da (3 voti)
#3 da (-2 voti)

10

Questo mi ha perseguitato per così tanto tempo. Quando si esegue la programmazione MVC, qual è la migliore pratica di programmazione? Si dovrebbero usare modelli completamente popolati o quelli parzialmente pieni, specialmente quando so che per questo particolare compito avrò bisogno solo di 2 campi dall'oggetto modello che ne ha altri 5?

A volte sembra proprio criminale riempire una lista di 20 oggetti del modello con tutti i valori del database quando sai che ne avrai bisogno solo alcuni.

Naturalmente il modello parziale significa che dovrai scrivere un altro metodo nel tuo DAO, a parte quello che recupera tutto. Quale significa più codice da mantenere?

D'altra parte tirare tutto dal DB con i modelli completamente popolati significa che un metodo serve a tutti, ma questo ovviamente ti darà un po 'di overhead delle prestazioni.

Riesco a vedere ORM (come Hibernate o ActiveRecord of Rails) che favorisce le tendenze nella programmazione MVC e database come i modelli BigTable di Google sono accettati. Ma cosa succede se usi ancora il buon vecchio JDBC?

L'hardware è economico, lo sviluppo è costoso. È proprio vero anche quando l'app deve scalare a poche centinaia di migliaia di richieste all'ora?

mvc

posta Pritam Barhate 26.04.2011 - 20:41

fonte

3 risposte

Leggi altre domande sui tag mvc

Gestori di comandi e DDD Buoni riferimenti per gli esempi di documentazione per l'utente finale e consigli [chiuso]

score 3 · Answer 1

Hai due opzioni:

1) Lascia alcuni campi nel modello non compilato

2) Crea un modello extra "lite" per la tua situazione specifica

Quale scegliere dipende ancora dalle due cose:

a) Quanti campi del modello "pieno" verranno ignorati

b) Con quale frequenza questo modello "lite" verrà istanziato

Se ci sono solo un paio o più campi che non possono essere riempiti, va bene andare con 1).

Se b) è solo una situazione individuale eccezionale, forse non ha senso creare un modello in più solo per un caso di utilizzo.

Un altro approccio è definire un modello "lite" ed ereditare il modello "completo" da esso.

score 3 · Answer 2

Se la tua vista richiede solo 2 proprietà dal modello, allora (probabilmente) hai il modello sbagliato per quel caso d'uso! Vorrei cercare di creare un modello adatto alla vista, salvare le ricerche DB aggiuntive e compilare solo i dati necessari. Se una vista successiva ha bisogno di maggiori dettagli, devi chiedere, ottengo i dati extra in seguito o dovrei avere tutto in anticipo ...

Come alternativa potresti guardare una sorta di valutazione pigra, quindi i valori vengono compilati quando ne hai bisogno. Questo può funzionare bene ma è ovviamente più lavoro e potrebbe finire per causare più round trip nel DB che non è grandioso se si finisce per farlo molto.

Detto questo, se in pratica stai selezionando alcuni campi aggiuntivi da una tabella o da una vista, il costo per ottenere quei dati extra è, a tutti gli effetti, zero (OK, ci sono più byte sul filo, ma il più grande è probabile che i costi siano nella creazione e nella distruzione di una connessione), quindi se c'è la possibilità che tu abbia bisogno di alcuni dati extra probabilmente popolerei il modello completamente una volta che sei felice di avere il modello giusto .

L'hardware è economico, ma nessuna quantità di hardware può compromettere il rendimento di un cattivo progetto.

score -2 · Answer 3

Il modello non è un DAO.

E un'altra cosa: se dici che hai 20 modelli (clienti, dal tuo esempio), allora questo non è un modello MVC. Il modello di dominio non esegue il mapping direttamente su una singola riga della tabella. Invece dovrebbe essere responsabile di tutte le operazioni eseguite con i tuoi "clienti".

Nel tuo esempio, "Cliente" non è un modello di dominio, ma solo un oggetto all'interno del modello.

Per quanto riguarda l'interazione con il database, tale responsabilità dovrebbe essere delegata a un oggetto data mapper , che dovrebbe sapere come archiviare e recupera le tue istanze della classe Customer.