Perché separiamo il recupero dei dati dalla vista?

Question

Perché separiamo il recupero dei dati dalla vista?

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

3

Sto cercando una buona argomentazione per:

Perché NON è una buona idea incorporare il codice di recupero dei dati nella mia vista?

Esempio

<tr>
    <td>Product</td>
    <td><select name="product">
        <option value="0">--</option>
        <?
        $sql = "SELECT id, model FROM product";
        $result = db_execute($sql);        
        for ($i = 0; $i < db_num_rows($result); $i ++)
        {
            $row = db_fetch_array($result);
            ?><option value="<?=$row['id']?>"><?=$row['model']?></option><?
        }
        ?>
        </select></td>
</tr>

In qualche modo, in teoria, posso capire che cose come "compartimentalizzare" costrutti di codice individuali nelle rispettive caselle (come la creazione di classi per la visualizzazione individuale o l'archiviazione persistente) possono essere utili, ma anche avere il codice nello stesso posto è vantaggioso . Posso vedere tutto proprio qui in un posto. I dati vengono trascinati nello stesso punto in cui viene visualizzata la casella select . Vedo la localizzazione (del codice che crea la casella select in un unico punto) come una buona cosa.

Separare correttamente (ovvero refactoring questo codice) significa creare un modello, controller, archiviazione dati, costrutti vista e tutti gli altri codici standard che lo accompagnano, dove letteralmente 4, 5, 6 o più classi devono venire insieme per eseguire la stessa funzionalità.

php mvc separation-of-concerns

posta Dennis 16.03.2016 - 17:43

fonte

3 risposte

Leggi altre domande sui tag php mvc separation-of-concerns

Perché la sintassi della dichiarazione di chiusura in Swift è diversa dalla dichiarazione di funzione Come chiamare un'eccezione in cui la condizione non è eccezionale

score 6 · Answer 1

Che cosa succede se due viste separate devono visualizzare i prodotti?

E il codice che deve modificare i prodotti?

Separando il codice di recupero in modo tale da restituire gli oggetti del modello appropriati, è possibile riutilizzare il codice. Il riutilizzo del codice significa che è implementato una volta e non può uscire dalla sincronizzazione in più posizioni, dove alcuni hanno dei bug e altri no.

Una vista dovrebbe essere più di un modello senza alcuna logica reale in luogo oltre ai costrutti come i loop che controllano direttamente la vista (cioè "per ogni prodotto, mostra questo elemento").

Man mano che un progetto cresce, è più facile trovare, modificare e correggere il codice quando si separano le preoccupazioni separate. Il riutilizzo del codice diventa più semplice, la correttezza del codice è più facile da testare.

Vedere il codice tutto in un posto è un argomento debole:

Dovresti essere in grado di avere più di una finestra di editor visibile alla volta. È possibile visualizzare sia la vista che il modello in finestre separate. L'era dei monitor quadrati a bassa risoluzione è passata.
Avendo il codice intrecciato in questo modo (vista, modello, vista di nuovo) in realtà lo stai rendendo più difficile da vedere in un modo: la vista (pagina web, in questo caso ) è frammentato a causa del codice incorporato in esso. Se vuoi vedere come gli elementi di visualizzazione vengono visualizzati in relazione tra loro, devi trascurare il codice che si trova in una lingua diversa. Questo è il motivo per cui anche il codice JavaScript dovrebbe essere esternalizzato a un file separato, nonostante sia strettamente accoppiato alla vista (è stato scritto per manipolare il DOM HTML).

score 1 · Answer 2

Verso la metà e la fine degli anni '90, il tuo stile di programmazione web era molto più accettato, proprio per le ragioni che hai affermato. È più semplice, più consolidato, con meno regole. In effetti, la facile attivazione di PHP di questo stile è un grande motivo per cui è diventato così popolare. Quando parliamo dei vantaggi di separare il modello e la vista, non dobbiamo dimenticare che c'è anche un costo significativo che stiamo pagando nel trade off. Vale la pena pagare il costo, ma è ancora lì.

Lo stile consolidato funziona bene per pagine molto piccole e cambiate di rado, ma quando si scala, i costi iniziano a superare i benefici. Se hai designer che lavorano sulle tue pagine, diventa più difficile integrare il loro lavoro con il tuo. Piccole modifiche al layout potrebbero influire negativamente sul modello e viceversa. Evitare la duplicazione diventa molto difficile. Cose come fare una versione mobile del tuo sito diventa molto difficile. Capire quale effetto a catena avrà un cambiamento sarà difficile. I test unitari diventano più difficili da mantenere.

Sì, hai dei costi aggiuntivi in anticipo che sono fastidiosi, ma con il tempo stai meglio. Inoltre, in realtà finisci con un codice che è più mirato e più facile da leggere, il che significa che non devi avere per saltare tra i tuoi file così diversi.

score 0 · Answer 3

Vedi codice front-end all'interno del tuo back-end? Non. Potresti averlo lì, ma sarebbe comodo? Per la maggior parte degli sviluppatori di back-end non lo sarebbe. Essendo io stesso uno sviluppatore di back-end, mi sento molto a mio agio nel leggere classi, metodi, vedere connessioni tra di loro, ecc. Il codice di front-end dovrebbe perfezionare il codice di back-end e renderlo molto più difficile per me, come sviluppatore di back-end , da leggere.

Considerando che io, un back-ender, non mi piace avere a che fare con il codice front-end, sono abbastanza sicuro (ed è in effetti così) che lo stesso si applica viceversa agli sviluppatori front-end.

L'altra cosa è la separazione delle preoccupazioni, come ha già indicato Snowman. Hai un bug in PHP? Tutto quello che dovrai correggere sono .php file. Bug in JavaScript, apri un file .js . Vuoi cambiare il modo in cui i dati dei front-end vengono visualizzati? Tocchi .html (o il tuo modello) file.

Tuttavia, anche se sono molto influenzato dai progetti aziendali, se stavo realizzando un'applicazione molto semplice, molto semplice, probabilmente dovrei scaricare tutto in un unico file solo per farlo. Ma se si va fino all'adozione dell'architettura MVC, è necessario rispettare le convenzioni e fare operazioni specifiche nei luoghi, a cui appartengono.