Utilizza il modello per "tutto" in MVC?

4

Questa domanda è il risultato della discussione QUI ed è stata spostata da HERE .

È davvero una buona pratica fornire OGNI valore che visualizzi in qualsiasi vista tramite un modello?
Soprattutto variabili come il nome utente corrente. Anche Microsoft odora quanto segue nel modello predefinito per _LoginPartial in ASP.NET MVC 3 +:

"Hello " + User.Identity.GetUserName() + "!"

Penso che sia giusto non fornire questo tramite un modello poiché è molto meglio alla luce della manutenibilità. O dovresti obbedire alle "regole MVC" e aggiungere un modello / sottomodello a ogni pagina / modello per fornire tali elementi e passarli nelle viste e nei parziali?

Come risolvi questi "problemi" o quale pensi sia il modo migliore di fare queste cose?

L'ereditarietà sarebbe un'opzione:

public class BaseUserModel
{
    public string UserName { get; set; }
}

Richiede che ogni modello erediti da un modello di base come sopra contenente tali valori.
Ma questo potrebbe causare problemi se hai bisogno / vuoi ereditare un'altra classe per qualche modello?

    
posta ChrFin 25.04.2014 - 17:29
fonte

2 risposte

2

User è un modello, nel senso generico della parola, anche se non secondo la definizione più ristretta di Microsoft nella loro particolare implementazione del modello MVC. Non stai facendo qualcosa come User.OutputGreeting() , quindi il modello e la vista sono ancora separati, con tutti i vantaggi concomitanti. L'unica cosa che ti stai perdendo è parte dello zucchero fornito dal framework.

Non ha senso mettere più impegno e più complessità per fare qualcosa "nel modo più semplice". Inoltre, la creazione di un altro modello per qualcosa già fornito viola principi di progettazione come unica fonte di verità .

    
risposta data 25.04.2014 - 18:08
fonte
0

Inheritance

Ho già utilizzato l'ereditarietà come soluzione per il trasferimento di dati comuni a molte delle stesse pagine (utente, ruolo, registrazione / registrazione eventi, informazioni sul profilo e altri dati). Questo è conveniente in alcuni casi, ma non sempre l'ideale. Ad esempio, puoi aggiungere i dati del profilo al modello di base per le pagine in cui possono aggiungere il loro indirizzo email o visualizzare la loro immagine del profilo, e questo può essere usato su molte pagine, ma molte pagine questo modello potrebbero non essere usate affatto essere uno spreco.

Modello contenitore

Un'idea migliore secondo me è creare modelli specifici per la tua vista. In questo modo è possibile aggiungere diversi modelli a un singolo modello di contenitore e ciascuna vista può avere il proprio set personalizzato di modelli senza portare modelli aggiuntivi che non sono necessari per quella vista (diversamente dall'idea di ereditarietà). È quindi possibile includere il modello del profilo nelle viste che lo richiedono ed escluderlo nelle viste che non lo fanno. Una caratteristica che mi piace particolarmente di questa idea è che puoi includere sottomodelli per le viste parziali che possono concentrarsi solo su quel modello e essere riutilizzati su molte altre viste.

Chiamate API modello + web

Un'altra strategia che ho usato è un mix di modelli e chiamate API Web. Un modello principale per la pagina, ma alcune parti della pagina potrebbero ottenere / impostare i propri dati tramite una chiamata API, ciò che ho trovato è utile per parti più piccole della pagina o parti della pagina comunemente usate. Questo potrebbe non essere il migliore da un punto di vista purissimo, ma l'ho trovato utile in situazioni pratiche. Gli esempi più comuni per me sono in genere griglie o controlli personalizzati. Avrò un modello per la pagina, ma alcune griglie o controlli sulla pagina otterranno i loro dati dalle chiamate API che in genere restituiscono XML o Json e possono essere manipolate tramite Javascript / jQuery.

    
risposta data 18.04.2015 - 19:10
fonte

Leggi altre domande sui tag