Основная структура MVC (PHP)

Вы действительно можете поместить что-нибудь в такое представление, которое вам бы хотелось, но чтобы лучше придерживаться способа MVC делать вещи, вы должны ограничить PHP в представлении простым echo или print (возможно, даже небольшие петли), хотя даже те может быть предварительно вычислено в контроллере / модели). Поскольку это единственный способ получить динамический контент, было бы немного глупо сказать, что они не разрешены.

Идея представления состоит в том, чтобы позволить ему иметь больше HTML-взгляда, чтобы разработчики интерфейсов или люди, которые не знают PHP, могут легко работать с файлом, не запутываясь.

Обновить

Чтобы узнать больше о MVC в целом, вы можете увидеть любой из них (там есть масса обучающих программ):

http://blog.iandavis.com/2008/12/09/what-are-the-benefits-of-mvc/

http://php-html.net/tutorials/model-view-controller-in-php/

http://www.tonymarston.net/php-mysql/model-view-controller.html

Чтобы увидеть конкретные примеры PHP с использованием MVC, я предлагаю загрузить некоторые из более предварительных фреймворков (таких как CodeIgniter , Symfony или Drupal ) и просто просматривать код. Попытайтесь выяснить, как это работает, а затем воссоздать функциональность для простой системы на основе статей.

Вот несколько вещей, которые вы должны учитывать:

• Вы не можете делать классический MVC в PHP. Вместо этого у нас есть шаблоны, вдохновленные MVC
• Существует связь 1: 1 между представлениями и экземплярами контроллера, когда они реализованы для сети
• Модель в MVC не является классом. Это слой, который содержит много разных классов
• Просмотр не является немым шаблоном, а экземпляром класса, который имеет дело с логикой представления

Просмотр в веб-MVC

Как указано выше, представления в шаблонах с MVC и MVC отвечают за логику представления. Это охватывает такие вещи, как отображение сообщений об ошибках и разбиение на страницы. Для этого каждый вид может обрабатывать несколько шаблонов.

Просмотр получает информацию из слоя модели и действует соответственно. Способ, которым информация из уровня модели заканчивается в представлениях, является одной из самых значительных различий в шаблонах MVC-ish:

• классический шаблон MVC

  Структуры из слоя модели отправляют информацию для просмотра, когда состояние модели было изменено. Это делается с помощью шаблона наблюдателя .

• Модели Model2 MVC и HMVC

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

• Модели MVVM и MVP

  Просмотр получает информацию через контроллер, который, в свою очередь, запрашивает его с уровня модели. Дальнейшее различие в шаблонах связано с тем, что делать с данными, прежде чем передавать их для просмотра.

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

Так как насчет этого «приветственного» сообщения?

Чтобы показать приветственное сообщение, ваше представление должно запрашивать у слоя модели имя текущего пользователя. Если модельный слой возвращает какое-то состояние ошибки, просмотр выбирает шаблон сообщения об ошибке и вставляет его в макет.

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

В каком порядке должны быть загружены детали?

_{Идея, что контроллер должен инициализировать модель и представление, исходит из очень примитивной интерпретации MVC для Интернета. Шаблон известен как page controller , который пытался трансформировать MVC непосредственно на статические веб-страницы.}

На мой взгляд, это должен быть порядок:

1. Модель

   Вы инициализируете структуру, через которую вы будете иметь дело с модельным слоем. Скорее всего, это будет своего рода сервисная фабрика, которая позволит вам создавать такие вещи, как служба Authentication для входа в систему и Library сервис для обработки документов. Такие вещи. Я написал немного длинный комментарий о структуре слоя модели ранее. Вы можете найти это полезным.

2. Посмотреть

   Вы создаете экземпляр представления на основе информации, которую вы собрали из механизма маршрутизации. Если вы используете Model2 или HMVC , то вашему представлению потребуется экземпляр Service Factory в конструкторе.

   Если вы используете MVVM или MVP , конструктор представления не имеет особых требований.

3. контроллер

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

После инициализации базовых элементов MVC вы вызываете метод на контроллере и визуализируете текущий вид.

Просто имейте в виду, что это очень упрощенное описание.