È sbagliato avere stringhe HTML all'interno di oggetti PHP o è solo sbagliato nei controller?

2

Ho sempre pensato che nel tipico design MVC è una cattiva pratica costruire e amp; concatena stringhe HTML in qualsiasi file o classe PHP che non sia strettamente un modello.

Sto lavorando su un grande progetto con linee guida rigorose, e mentre è vietato inserire qualsiasi codice HTML nel controller PHP, è giusto che il gioco abbia sotto-oggetti PHP che potrebbe generare molte stringhe di codice HTML che vengono poi passate nel modello.

Questi "sottooggetti" contengono una logica aggiuntiva che potrebbe cambiare l'HTML a seconda delle condizioni.

Quindi le mie 2 domande principali sono:

  1. Questo è considerato MVC?
  2. Questi oggetti sono considerati parte della vista o sono un franco sul modello e sulla vista?

Esempio:

<?php
/* controller.php */
class KittenController {

    protected $view = 'view.html';

    public function render (Request $request) {
        $data = $this->getDynamicData(); // get some data
        $object = $this->getObject();  // get a PHP object
        $this->setField('foo', $data['bar']);
        $this->setField('baz', $object->render());
    }
}

<?php
/* object.php */

class Object {
    public function render () {
        $html = '';
        $html .= '<div class="my-cool-html">';
        if ($this->hasDuck()) {
            $html .= '<p>I have a duck...</p>';
        }
        else {
            $html .= '<p>No duck here...</p>';
        }
        $html .= '</div>';

        return $html;
    }
}

<!-- an html template -->
<html>
<body>
<div class="blah">
    [[foo]]
</div>
<footer>
    [[baz]]
</footer>
</body>
</html>
    
posta Michael Butler 08.04.2014 - 01:34
fonte

2 risposte

3

L'intera idea di MVC è Separation of Concern e l'introduzione di qualsiasi metodo che costruisca / generi qualsiasi forma di mark-up come quello che stai facendo nel tuo esempio, anche senza emetterli direttamente, lo stai violando. Quindi questo non è più MVC.

Nel tuo esempio, la modifica del design / mark-up di un designer richiede una modifica nel tuo object.php da parte di un programmatore. Inoltre potresti finire con un pasticcio come il mark-up è ovunque nelle classi del tuo progetto e le tue viste sono solo il layout generale.

Se non stai costruendo qualcosa su MVC , ovviamente puoi costruire diversi livelli, strutturare l'applicazione in modo diverso e avere anche un markup generato da classi come quello che hai nel tuo esempio; Tuttavia, l'approccio successivo non è generalmente raccomandato.

Quello che consiglio è di ridimensionare la tua classe Object con qualcosa di simile al seguente, dove hai ancora la separazione di preoccupazione applicata; Il tuo codice PHP all'interno del metodo render si prenderà cura della logica di business e la Vista parziale corretta verrà caricata e restituita alla fine.

class PetHelper {

    private $view = null;

    public function render ( Child $child ) {

        if ( true === (bool) $child->hasPuppy() ) {
            $this->view = 'walk-the-puppy.html';
        } else {
            $this->view = 'play-with-kitten.html';
        }

        return $this->view;
    }
}
    
risposta data 08.04.2014 - 07:40
fonte
2

Hai bisogno di guardare questi sottooggetti e quale logica contengono.

Qualcosa deve decidere come contrassegnare il testo. Come chiarisce la tua domanda, il controllore non dovrebbe (e nel tuo caso, non lo è) il luogo in cui ciò si verifica.

Questi sotto oggetti possono essere considerati parte della vista, in quanto contengono codice responsabile dell'assemblaggio delle parti dinamiche della vista.

Se disponi di oggetti dati che fanno parte del modello e emettono HTML? Questa è una violazione della separazione di MVC. Alcuni oggetti eseguono decisioni non strettamente correlate alla vista (ad esempio calcolando quante righe in una tabella) e emettono anche HTML? Anche una violazione della separazione.

A volte potresti scoprire che non sei in grado di applicare MVC o altri pattern al 100% a causa di vincoli al di fuori del tuo controllo come la lingua o il framework. Va bene fudge un po 'per applicare MVC in quel caso, basta documentarlo e provare a localizzare la bruttezza in una classe o in un piccolo insieme di classi. Non sono sicuro che sia quello che sta succedendo qui, comunque. Tieni a mente che dovresti provare ad aderire a MVC il più possibile se questo è il modello che hai scelto, ma va bene deviare leggermente se c'è una ragione sufficiente. Si tratta di comprendere i principi e come applicarli, quindi rivedere il codice come una squadra per determinare quanto aderisce a qualsiasi modello particolare di progettazione. Se non aderisce rigorosamente a MVC, la domanda importante diventa vale la pena refactoring per renderlo "migliore" o il codice è gestibile così com'è? Ma questa sarebbe una domanda a parte.

    
risposta data 08.04.2014 - 03:09
fonte

Leggi altre domande sui tag