Viste incapsulate in MVC

Question

Viste incapsulate in MVC

#1 da (1 voti)

0

Questa è una domanda di architettura / design che mi è venuta in mente quando ho confrontato le attuali pratiche MVC in PHP con lo sviluppo basato su componenti in Javascript.

La mia domanda è:

Perché la vista (o parti della vista) non definisce quali dati dovrebbero essere usati per visualizzarlo?

Sembra essere una pratica comune in MVC Frameworks lasciare che il controller definisca i dati necessari alla vista. Per me questo crea un accoppiamento inutilmente tra il controller e la vista.

Quando la libreria della vista ha la possibilità di chiamare le funzioni (ramoscello per esempio) che recuperano le strutture dati necessarie, perché non sarebbe preferibile? Il controllore dovrebbe solo sapere quale vista radice rendere e parti della vista funzionerebbero quindi con il modello per leggere i dati necessari per il rendering stesso. Vedo i seguenti vantaggi:

I controllori diventano più semplici poiché non aggregano i dati prima di visualizzare la vista
Le strutture dati inutilizzate passate alla vista si sarebbero verificate molto meno
Riutilizzare parti della vista (modelli) sarebbe anche più facile in quanto non dipendono dal rendering del controller per renderlo più

Ovviamente quando si cambiano i dati la logica rimane nel controller, ma mi riferisco solo alla lettura dei dati per visualizzare l'interfaccia utente. Alcuni dati (ad esempio dopo l'invio di un modulo) devono ancora essere passati alla vista dal controller, ma la maggior parte di essi potrebbe essere inserita in componenti di renderizzazione indipendenti.

Vedi qualche svantaggio di questo approccio? Hai già provato qualcosa di simile a questo con un framework MVC?

design clean-code php mvc component

posta Matteo De Micheli 13.07.2017 - 20:29

fonte

1 risposta

Leggi altre domande sui tag design clean-code php mvc component

Tutte le combinazioni di attributi Get / SetAccess, Access e Dependent property hanno casi d'uso validi? Redux: Quando dovrei tenere traccia di stato e quando non dovrei?

score 1 · Accepted Answer

Le viste in MVC dovrebbero essere stupide. Dovrebbero essere poco più che i modelli che prendono i dati e formattano i dati in modo consumabile. Il cambiamento che suggerisci funzionerebbe sicuramente, ma ci saranno alcuni aspetti negativi:

Visualizza ora ha più di una responsabilità. Deve recuperare i suoi dati e formattare i suoi dati. Violare SRP.
La vista non può essere riutilizzata con dati diversi. Questo rende i test più difficili. Idealmente puoi testare la tua vista unitamente passando i dati e controllando l'HTML.
Le visualizzazioni alternative che utilizzano gli stessi dati devono reimplementare la stessa logica. Ad esempio, se si desidera l'output XML, HTML e JSON da un controller, ognuna di quelle viste avrebbe la stessa logica per il recupero degli stessi dati. È meglio che il controller recuperi i dati e li passi alla vista appropriata.
Il passaggio all'app client è più semplice quando il controllore mantiene la logica. Se si desidera spostare la vista sul browser, è necessario che il controller esegua l'aggregazione dei dati per motivi di prestazioni. Non è possibile fare molte richieste HTTP dal client per recuperare tutti i dati.

... this creates unnecessarily coupling between the controller and the view

Sì, il controller è accoppiato alla vista in qualche modo, ma dovrebbe essere un accoppiamento lento che consente di testare il controller senza testare la vista. In PHP puoi usare le interfacce per ottenere una bella relazione liberamente accoppiata tra controller e view:

interface iUserView {
    public function render($user);
}

class HtmlUserView implements iUserView {
    public function render($user) {
        return <<<HTML
          <html>
             <body><h1>{$user->name}</h1>
             </body>
          </html>
HTML;
    }
}

// Could implement a JSON version of the view, or an alternate HTML view
class JsonUserView implements iUserView {
    public function render($user) { ... }
}

class UserController {
    public function __construct(iUserView $userView) {
        $this->userView = $userView;
    }

    public function getUser($userId) {
        $user = // get user by $userId
        $this->userView.render($user);
    }
}