Biorąc pod uwagę koncepcję „chudych kontrolerów, grubych modeli” i ogólną akceptację, że widoki mogą bezpośrednio wywoływać modele, gdy wymagają danych do danych wyjściowych, czy należy rozważyć obsługę części „pobierania i wyświetlania” żądań w widokach, a nie kontrolera? Na przykład (próbował zachować kod dość ogólny):
Kontroler
<?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');
}
}Widok
<?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>Dla mnie ma to przynajmniej sens w przypadkach, w których żądanie jest zasadniczo tylko widokiem. Dlaczego administrator powinien zbierać i przekazywać dane do widoku, skoro może je po prostu odzyskać? To pozostawia kontroler otwarty na przetwarzanie „na poziomie aplikacji” (np. Obsługę żądań GET / POST, zarządzanie prawami dostępu i uprawnieniami itp.), A także zachowanie Modelów wielokrotnego użytku i innych dobrych rzeczy.
Jeśli ten przykład został rozszerzony, aby umożliwić użytkownikowi filtrowanie wyników, kontroler po prostu obsłużyłby test POST z formularza i przekazał filtry do widoku, który następnie zażądałby danych ponownie, tym razem z filtrami.
Czy jest to poprawne podejście do tworzenia aplikacji MVC? Czy też pomijam ważną rolę, jaką powinien odgrywać Kontroler?
offers_model->get_latest()? Dodanie tego do każdej metody w kontrolerze (jak wcześniej głupio próbowałem) wydaje się przesadą i wyraźnie pozbawione SUSZENIA.