Il modello / vista in MVC dovrebbe essere concreto o generico?

Question

Il modello / vista in MVC dovrebbe essere concreto o generico?

#1 da (2 voti)
#2 da (0 voti)

1

Nel modello MVC, il modello e la vista dovrebbero essere molto concreti e adattati al componente rappresentato? O dovrebbero essere il più generici possibile in modo che possano essere facilmente riutilizzati?

Caso specifico

I miei dati sono una lista di fotogrammi registrati. Ogni frame può essere costituito da più blob di dati, ad esempio un'immagine e alcuni metadati:

Approach (1) : potrei usare un generico TableModel per rappresentare i dati registrati e un generico TableView per visualizzarlo: Ogni colonna rappresenta un frame e ogni riga rappresenta un tipo di dati. Ad esempio, una riga è l'immagine, una riga è una descrizione dell'immagine inserita dall'utente, ecc.
Approach (2) : potrei creare uno specifico RecorderModel , che forse riutilizza il generico TableModel e uno specifico RecorderView , che forse riutilizza il generico TableView .

Quest'ultima opzione sembra preferibile, poiché il modello e la vista possono essere facilmente modificati se vengono richieste modifiche specifiche. Tuttavia, sembra che finirei con un sacco di classi vuote come RecorderModel / RecorderView che racchiudono solo il generico TableModel / TableView .

Ci sono delle insidie o importanti vantaggi / svantaggi di cui dovrei essere a conoscenza? C'è un consenso generale come usa sempre modelli generici, usa sempre viste concrete o qualcosa di simile? Dipende dal framework MVC usato?

architecture mvc specialization

posta pschill 01.08.2018 - 10:12

fonte

2 risposte

Leggi altre domande sui tag architecture mvc specialization

Database per approccio tenant, server di database singoli o multipli? Dove convertire int enum in un'architettura a 3 livelli?

score 2 · Answer 1

Uno degli aspetti chiave di MVC è che il modello è indipendente dalle visualizzazioni. In effetti, il modello può essere rappresentato da più viste e ogni modifica ai dati del modello dovrebbe essere visualizzata in tutte le viste pertinenti (in genere utilizzando il modello di osservatore).

Quindi, se si avvia un progetto MVC prevedendo un'associazione cablata tra classi di modelli specifici e classi di viste specifiche, si è certamente sulla strada sbagliata.

Prova ad immaginare un esempio più completo con due viste: una che mostri la tabella dei singoli fotogrammi, ma un'altra che mostri un grafico di distribuzione del colore di uno specifico fotogramma selezionato.

Quindi il modello non dovrebbe conoscere alcun dettaglio specifico di una determinata vista. Dovrebbe conoscere solo le viste pertinenti da notificare di qualsiasi modifica dei dati. E ovviamente dovrebbe conoscere l'interfaccia da utilizzare per la notifica. Questo parla strongmente a favore dell'approccio generico per la vista . A proposito, i framework MVC si occupano in generale di questo.

Il problema non è simmetrico: una vista è autorizzata a interrogare il modello per la visualizzazione delle informazioni. In effetti, ha bisogno di conoscere bene il modello. Quindi la vista generica deve essere specializzata e la specializzazione deve conoscere l'interfaccia specifica per interrogare il modello. Se riuscissi a definire un'interfaccia di query generica, risparmierai un sacco di codice specifico quando il modello verrà esteso in seguito. Ma questo approccio potrebbe richiedere un sovraccarico e una complessità aggiuntivi; utilizzando nelle viste la vera interfaccia specifica del modello sembra quindi un approccio valido.

score 0 · Answer 2

C'è una strong argomentazione per una mappatura uno a uno di View e ViewModel.

In un'app MVC, solitamente la vista riceverà un ViewModel anziché il modello o le entità della logica aziendale sottostante. Anche se ViewModel è una semplice raccolta di Modelli con alcuni campi aggiuntivi, pronuncia per l'impaginazione o un nome utente. cioè potrebbe essere più correttamente chiamato M-VM-VC anche se ancora diverso da MVVM

Una volta che hai il livello di astrazione del ViewModel, queste diventano lezioni di lancio che organizzano semplicemente i dati in un modo che è utile per la Vista.

Se hai bisogno di una Vista leggermente diversa, è più facile e più pulito creare una nuova classe ViewModel che supporti qualsiasi funzionalità aggiuntiva di cui ha bisogno la nuova Vista, tale da rendere il ViewModel esistente abbastanza generico da gestire entrambi i casi.

Tuttavia, è solo perché il Modello sottostante è abbastanza generico da essere utilizzato in entrambi i ViewModels che è possibile.