MVC... как и почему, и какие еще хорошие варианты есть (PHP)?

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

Так что все они были чем-то вроде...

MODEL
class User{
    function getUser($userID){
      $sql = mysql_query('SELECT name......');
      // more code.....
      return $array
    }
}

VIEW
<h2><?php echo $user['name']; ?></h2>

CONTROLLER
class Controller{
    $userModel = new User;
    $userInfo = $userModel->getUser($id);

    $template = new Template('usertemplate.tpl');
    $template->setVariables($userInfo);
    $template->display();
}
Я понимаю, почему модель состоит из классов, которые просто получают и сохраняют данные (хотя я предполагаю, что классы не всегда необходимы и функции могут быть использованы). Я поймите, почему шаблон состоит в основном из HTML. Но я не понимаю, почему контроллер-это класс. Я бы предположил, что контроллер является процедурным скриптом (например, userprofile.php, который получает данные пользователей из модели и отправляет их в шаблон для отображения).

Кроме того, мне было интересно, почему каждый учебник, который я читал, имел дело с переписыванием модов и использованием одной страницы с запросами в url, например " index.php?user=1", или индекс.php?news=3 для запуска всего сайта. Что с тобой не так? наличие отдельных страниц, таких как user_profile.php?id=1, или новости.php?id=3...

Может кто-нибудь помочь мне с быстрым "учебником" и объяснением по пути. Нравится...как будет реализована регистрационная форма с использованием MVC, что пойдет куда и зачем? спасибо

ПС. какие еще существуют шаблоны проектирования

4 3
php separation-of-concerns model-view-controller

4 ответа:

Большой "выигрыш" контроллера в версии PHP MVC заключается в том, что вы избавляетесь от необходимости иметь отдельную страницу PHP для каждого URL-адреса, на который реагирует ваше приложение.

Когда для каждого URL создается новая отдельная страница, вы ожидаете, что ваши разработчики (или вы сами) извлекут необходимые библиотеки и инициализируют механизм шаблонов/макетов таким же образом. Даже если вы являетесь единственным разработчиком, искушение отказаться от" стандартного " способа делать вещи обычно заканчивается будучи слишком сильным, это означает, что каждая URL / PHP-страница становится собственным мини-приложением вместо того, чтобы каждая URL/PHP-страница была частью одного и того же приложения. Когда у вас есть несколько разработчиков, это гарантированно произойдет.

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

Фреймворки MVC также упрощают предоставление удобных URL-адресов для вашего сайта. Обычно в системе маршрутизации происходит достаточно событий, чтобы вам не пришлось прибегать к огромному количеству переменных строки запроса. Читаемые URL-адреса-это плюс для SEO и для опытных пользователей.

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

1

Использование одной страницы с запросами в url-адрес типа " index.php?пользователь=1", или индекс.php?новости=3, чтобы запустить весь сайт. Что плохого в том, чтобы иметь отдельный страницы, как имя_пользователя.php?id=1, или новости.php?id=3...

Использование одной точки входа упрощает некоторые вещи, я полагаю:

  • вам не нужно дублировать какую-либо часть кода в user_profile.php и новости.php
  • Если вы хотите настроить какой-либо фильтр (например, PHPIDS для безопасности или ACL, для например), у вас есть только один файл для изменения, и это делается для всего приложения.

ПС. какие еще модели дизайна есть ли

Есть много шаблонов проектирования; вы можете найти список в статье Design pattern (computer science) в Википедии, например-со ссылками на страницу каждого из них, для получения более подробной информации.
1

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

На самом деле важно сохранить разделение различных проблем. Логика базы данных входит в ваши модели, логика компоновки входит в шаблоны, и все остальное в контроллере.

Таким образом, для действительно простого примера вы могли бы иметь скрипт " Регистрация.php " со следующим кодом

$signup_options = SignupOptions::getSignupOptions(); // Load some data      
require("register_form.php");  // Pass it to the view

И это сообщение для register_process.php 

$username = $_REQUEST['username'];
$password = $_REQUEST['password'];
$email    = $_REQUEST['email'];
Users::Register( $username, $password, $email );
header( 'location: register_success.php' );

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

Другим распространенным шаблоном проектирования является "вид-помощник", который это место, где вы вызываете шаблон напрямую, а шаблон вызывает объект "помощник", который выполняет бизнес-логику между шаблоном и моделями. Аналогично по концепции, но вы можете пропустить любой дополнительный код для шаблонов, которые в нем не нуждаются, сохраняя при этом разделение проблем, таких как MVC. (Разница заключается в том, что вы вызываете шаблон напрямую, а не вызываете контроллер).

0

Существует несколько способов реализации хорошего приложения, но я просто коснусь нескольких концепций. Эти понятия взяты из Samstyle PHP Framework.

Во-первых, у вас есть следующие компоненты: Model (Table Data Gateway), View, View Controller и Backend Controller.

Этот контроллер вида фактически управляет тем, как вид будет выглядеть (например, отображать регистрационную форму). Серверный контроллер обрабатывает пользовательские данные на сервере и взаимодействует с ним. база данных Model).

Таким образом, здесь мы можем легко интегрировать Post-Redirect-Get в него.

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

Пользователь использует форму, отправляет и затем будет отправлен на серверный контроллер деки.php . Серверный контроллер проверяет, проверяет, а затем передает данные в функции (Table Data Gateway), которые помогут вам взаимодействовать с база данных. После завершения взаимодействия пользователь перенаправляется либо на страницу успеха, либо на страницу регистрации с ошибкой.

В модели (табличный шлюз данных) у вас фактически есть функции, которые принимают массив и затем CRUD с базой данных.

0