Un modo corretto di lavorare con MVC

Question

Un modo corretto di lavorare con MVC

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

1

Oggi sono entrato in un dibattito al lavoro, spero che tu possa aiutarmi a sistemarlo.

Il mio collega desidera separare UI, Modello, DB e Rete in questo modo:

Crea un livello API tra l'interfaccia utente e il controller, che consentirà l'interfaccia utente per interrogare tutti i modelli nell'APP.
Ci sarà un altro controller che interromperà i modelli le loro rappresentazioni DB (Es .: UserTablesModel, ScoreTableModel ...), Sarà un singleton chiamato DBControler e lo farà Fornire anche alcuni metodi di utilità per interrogare il DB (Es: insert (tableName, value ...).
ModelTables utilizzerà l'hub eventi per notificare all'interfaccia utente modifiche di stato, e saranno aggiornati dal livello di rete usando DBControler di riferimento.

Questa idea non mi piace perché crea un accoppiamento tra modelli non collegati nel livello controller. Penso che sarebbe più saggio consentire all'interfaccia utente di accedere direttamente ai Modelli (magari renderli singleton) e spetta al modello offrire un'API adeguata per accedere ai propri dati e fornire un callback di eventi per notificare il suo cambiamento di stato (nessun evento hub). Mi piace la parte che i modelli devono essere aggiornati direttamente dal livello di rete.

Inoltre, non mi piace il nome TableModel, penso che il DB debba essere un servizio accessibile dal modello, un modello può accedere a più tabelle.

Qual è il modo corretto di lavorare con MVC?

mvc mvp

posta Ilya Gazman 10.11.2015 - 09:34

fonte

2 risposte

Leggi altre domande sui tag mvc mvp

Ci sono argomenti per l'utilizzo di una variabile del logger locale Come mitigare la complessità dei fallback introdotti per riprovare automaticamente in caso di fallimento?

score 3 · Answer 1

Consiglio vivamente di consultare viewmodels . Il modo in cui i dati vengono presentati nel database non è sempre come lo si vorrebbe presentasse nell'interfaccia utente.

Un esempio comune sono i prezzi, in cui potrebbe essere memorizzato come int o decimale nel DB. Tuttavia, nell'interfaccia utente, potresti desiderare che il simbolo di valuta e il raggruppamento delle cifre siano tali:

$ 1,999 anziché 1999.

L'aggiunta di questa logica all'interfaccia utente o al modello non ha senso - e con un viewmodel, l'interfaccia utente & il modello può essere tenuto pulito: l'interfaccia utente serve solo i dati, il modello viewmodel contiene solo i dati e la logica richiesti e il modello memorizza la rappresentazione iniziale dei dati.

Questa pagina descrive il suo uso in ASP.NET MVC, ma i principi generali sono sani.

score 0 · Answer 2

Suggerirei Knockoutjs (semplicemente per interfacce utente JavaScript dinamiche), modello di architettura Model View-View Model (MVVM).

Di solito nel modello MVC, il Modello conserverà tutti i dati, la Vista è per le interfacce utente e Controller collegherà l'interfaccia utente e il modello.

Nel modello MVVM, Model-View visualizzerà dati dal tuo database, View-Model conserverà i dati temporaneamente in base all'input dell'interfaccia utente, una volta inviato o salvato, Controller ora fa il suo lavoro per convalidarlo e salvarlo nel tuo Database.

Analogia: 1. Ti do delle caramelle e tu le tieni tra le mani (MVVM) ma puoi farlo restituiscilo, loop .. 2. Se lo mangi e lo fai (Controller)