Il modello o il controllore scrivono i dati sulla vista in MVC e qual è l'uso del modello se abbiamo dati in archivio?

1

Ho letto diversi articoli, guardato video e letto domande qui, ma più leggo e apprendo su MVC - incluso MVCS o MVP in aggiunta .. per renderlo ancora peggio - più ampio sembra il pattern, quindi scusa se la domanda è ampia o lunga è solo perché voglio davvero capirlo e capire la sua combinazione.

Primo:

È il modello che scrive, rende o aggiorna i dati sulla vista, o è il controller, ho visto luoghi in cui lo sviluppatore usa il primo approccio, mentre il secondo è usato di più - cosa che per me è più sensato perché della coppia view-controller e dal momento che il modello è meglio separarlo, o questo è ciò che penso - ma anche con un semplice schema a blocchi , varia molto.

Secondo:

Avere questi codici logici generici per i due esempi:

Esempio 1:

// UserModel:
function getUsersDetails(id= false){
    if(id){
        // Fetch that specific user details with the id provided
    }else{
        // Fetch all users details
    }
}
// UserController:
result = UserModel->getUsersDetails(id) // id is optional depending on the view

Esempio 2:

// UserModel:
function getAllUsersDetails(){
    // Fetch all users details
}
function getUserDetails(id){
    // Fetch that specific user details
}

//UserController:

    //for ONE user details View
    result = UserModel->getUserDetails(id) 

    //for a View of ALL users
    result = UserModel->getAllUsersDetails() 

Quale degli esempi sopra è l'approccio migliore, personalmente suppongo che sia l'Esempio2 a causa della regola " nessuna logica nel modello ", ma se è così, questo mi confonde ancora di più quando alcune persone dicono " No SQL nel modello, invece mettilo nei repository o in uno Store ". Se il modello non deve contenere la logica, e meglio non contenere SQL, in che cosa consisterebbe allora, solo metodi vuoti che chiamano funzioni dai repository? questo non lo renderebbe inutile e aggiungerebbe più complessità all'intero design.

Mi scuso se il post ha molte domande o è ampio e Grazie in anticipo

    
posta Mi-Creativity 03.11.2015 - 07:05
fonte

1 risposta

2

MVC è un modello architettonico software per l'implementazione di interfacce utente. La sua forma concreta dipende molto dalle tecnologie utilizzate, quindi è difficile descrivere come funziona in dettaglio al di fuori del contesto di uno specifico stack di tecnologie.

Is it the Model which writes, renders or updates data on the View, or it's the Controller

La vista ha riferimenti al modello, che specifica quali dati vengono visualizzati come e dove. Il framework o il linguaggio di programmazione sottostante si assicura che gli aggiornamenti del modello vengano automaticamente propagati alla vista. Il codice sorgente del modello non ha riferimenti espliciti alla vista. Il controller può manipolare esplicitamente la vista, non per modificare i dati del modello, ma per scopi di interazione dell'utente. Il Controller non dovrebbe cambiare direttamente la presentazione dei dati del modello, ma dovrebbe cambiare il Modello e, così facendo, cambiare la Vista indirettamente.

Quanto sopra è la vista più comune su MVC, ma non è applicata per legge.

Which one of the above examples is the better approach

Questa domanda non è correlata al concetto MVC. È consentito disporre della logica aziendale nel modello (ad esempio, i controlli di convalida), ma non è consentita la logica di interazione dell'utente nel modello. La logica che descrivi non è né logica aziendale né logica di interazione dell'utente, ma è una questione di decomposizione del software. Penso che il secondo approccio sia migliore da una prospettiva di separazione delle preoccupazioni: una singola funzione non dovrebbe fornire una raccolta di dati e fornire un elemento da quella raccolta, a seconda di un valore speciale del parametro.

If the Model should not contain logic, and better not contain SQL , what would it be consist of then, just empty methods calling functions from the repositories?

Dipende dalla tua architettura dell'applicazione. Ad esempio, un'applicazione può essere costituita da tre livelli: il database, un livello di business logic o di servizi sopra di esso e quindi un livello di presentazione. In tal caso, MVC viene solitamente applicato solo nel livello di presentazione. Può (o non può) essere una decisione progettuale per consentire l'esecuzione della logica aziendale esclusivamente nel livello della business logic. In tal caso, il modello nel livello di presentazione non contiene alcuna logica, è solo un mucchio di dati, supportato da un framework o da un linguaggio di programmazione che assicura che i dati del modello siano sincronizzati con i dati del modello nel livello della logica aziendale e infine nel database. Ma anche altre architetture sono possibili. Spetta all'architetto del software chiarire le decisioni.

    
risposta data 03.11.2015 - 09:27
fonte

Leggi altre domande sui tag