Dato il concetto di 'skinny controller, modelli grassi' e l'accettazione generale che Views può chiamare direttamente su Models quando richiede dati per l'output, si dovrebbe prendere in considerazione la gestione delle parti 'get and display' di richieste all'interno delle viste e non del controller? Ad esempio (tentato di mantenere il codice abbastanza generico):
Regolatore
<?php
class Invoice extends Base_Controller {
/**
* Get all the invoices for this month
*/
public function current_month() {
// as there's no user input let's keep the controller very skinny,
// DON'T get data from the Model here, just load the view
$this->load->view('invoice/current_month');
}
}
Visualizza
<?php
// directly retrieve current month invoices here
$invoices = $this->invoice_model->get_current_month();
// get some other display-only data, e.g. a list of users for a separate list somewhere on the page
$users = $this->user_model->get_users();
?>
<h1>This month's invoices</h1>
<ul>
<?php foreach ($invoices as $invoice) { ?>
<li><?php echo $invoice['ref']; ?></li>
<?php } ?>
</ul>
Per me, questo ha almeno un senso nei casi in cui una richiesta è essenzialmente solo una vista. Perché il Controller deve raccogliere e trasmettere i dati alla Vista quando può recuperarli autonomamente? Ciò lascia aperto il controller solo per l'elaborazione a livello di applicazione (ad esempio gestendo richieste GET / POST, gestendo i diritti di accesso e le autorizzazioni ecc.) E mantenendo i modelli riutilizzabili e tutte le altre cose buone.
Se questo esempio è stato esteso per consentire a un utente di filtrare i risultati, il controllore gestirà semplicemente il POST dal modulo e passerà i filtri alla vista, che richiederebbe di nuovo i dati, questa volta con i filtri.
Questo è un approccio valido allo sviluppo di un'applicazione MVC? Oppure sto trascurando una parte importante del ruolo che un Controller dovrebbe svolgere?
