MVC, правильно ли таким образом инклюдить модель и view в контроллер?

Question

[Андрей Рабой]

Вопрос в заголовке, правильно ли инклюдить таким образом представление и модель в контроллер?
Может у кого-то есть другие варианты? Дайте ссылку на "канонический" образец MVC (да, знаю, такого нет, но лично для вас, который не стыдно посоветовать), видео, мануал, хоть код на почту. Проблема в том, что разобраться в правильном принципе работы MVC на примере готовых проектов новичку тяжело. В идеале - облегченный код, только демо MVC. Пардон за наглость))

<?php
//подключим класс модели
include_once ROOT_DIR.'/models/Home.php';

class HomeController {
    public function __construct() {
    }
    public function actionView() {
        // выбераем данные из модели Home и статического метода getItemAll
        $item_all = Home::getItemAll();

	// подключаем представление для данного метода
        include ROOT_DIR.'/views/home/index.php';
    }
}

Comments

[copal]

Не имеет значения, как в контроллер попадают ссылку на модель и представление, это уже к mvc не относится. Но нужно например понимать что сама вью не может засунуть ссылку на саму себя в контроллер, так как она не может иметь ссылку на контроллер.

Answer 1

[index0h]

По хорошему у вас require_once должен быть 1 раз указан в проекте, причем он должен загружать автозагрузчик composer.

View по хорошему должен на вход получать название шаблона для рендеринга и список значений для замен в плейсхолдерах.

Посмотрите Symfony, Silex

Answer 2

[Сергей Протько]

Дайте ссылку на "канонический" образец MVC

MVC образца 1979-ого года (канонический) подразумевает то, что контроллер ничегошеньки не знает о view. Он ловит события с инпутов и конвертит асинхронные действия пользователей в вызовы методов модели. Имеется в виду модель нашей логики, модель приложения, не обязательно один класс но целая иерархия которая сама может включать сколько угодно слоев и иметь сколь угодно большую сложность. Контроллер детали реализации модели вообще не парит, инкапсуляцию для этого придумали.

Так вот, View же напрямую подключается к модели и через обсервер подписывается на обновления состояния модели, и в случае оного актуализирует себя под текущее состояние.

Ну это если мы говорим про олдскульный MVC который в чистом виде никто не применяет уже лет 15-20. Ну и на бэкэнде в этом нет особо смысла так как модель в рамках одного запроса-ответа поменяться дважды у нас не должна. Просто пробрасываем все необходимое текущее состояние во view и все хорошо.

В целом у нас всеравно есть зависимость view от модели, что не ок. Потому чуваки придумали Model View Adapter (можно считать это вариацией MVP но есть нюансы).

Суть такая. В качестве адаптера сделаем контроллер, который будет получать данные формата UI (HTTP запрос в нашем случае) и будет генерировать данные для UI (HTTP ответ опять же). То есть задача контроллера сводится всего-лишь к тому что бы получить запрос, дернуть метод модели (один в идеале) и сформировать ответ.

Итог - полная независимость представления от модели и модели от представления. Конвертацией форматов орудует адаптер (в нашем случае это GRASP контроллер). Причем мы можем выстраивать целую цепочку адаптеров (концепция мидлвэров на этом строится), которую потом можно свести к одному главному фронт-контроллеру. Ну и подходит это не только для HTTP но и для всяких там MQ/CLI и других вариантов интерфейсов которые могут пригодиться в будущем (а могут и не пригодиться).

В случае с рендрингом стоит вынести это добро в отдельный компонент, что бы в контроллере можно было бы это все сделать вызовом одного-двух методов.

Ну и про буферизацию вывода не забываем.

p.s. хватит писать велосипеды, вы всеравно из этого усвоите мало чего. Возьмите какой-нибудь микрофреймворк, что бы можно было и в нутрах покопаться, и бойлерплейт пописать, и на основе уже готового подумать почему там так сделано.

Answer 3

[Алексей]

Могу посоветовать одну из лучших, на мой взгляд, простейшую реализацию MVC:
Build a PHP MVC Application

Answer 4

[Егор]

Судя по фрагменту кода, вас интересует не только MVC, но и "как инклюдить файлы с моделями и представлениями". Тогда вам следует почитать про композер, который не только позволяет ставить различные расширения и библиотеки, но и предоставляет автозагрузчик, который при наличии фронт контроллера вы инклюдите только один раз.
Почитайте вот это. Это из книги Symfony2 про переход от разработки на чистом PHP к использованию фреймворка. Расписано про изоляцию бизнес логики, представлений и контроллеров, что такое фронт контроллер, вообщем все как сейчас принято.