Попытка понять архитектуру приложения MVC

Question

Я новичок в MVC и пытаюсь понять, как MVC вписывается в то, к чему я привык.

Допустим, у меня есть простой статический веб-сайт со страницами: Главная, О нас, Контакты.

И скажем, у меня есть один шаблон xhtml / css, который будет отображать весь сайт. Для простоты в этом теге у меня будет переменная для содержимого страницы.

Так что в контроллере должна быть индивидуальная функция для контента для каждой страницы ????

Например:.

function home()
{
     $data['content'] = "<p>some html home page content</p>";

     $this->load->view('myView', $data);
}

function about()
{
     $data['content'] = "<p>some html about page content</p>";

     $this->load->view('myView', $data);
}

Итак, хотя я знаю, что это упрощенный вид, лучше ли создавать функции для каждой отдельной страницы?

Но что, если у вас есть сайт на 100 страниц? Разве контроллер не становится слишком большим для управления?

Но опять же, если бы у вас был один контроллер для каждой страницы, кажется, что им было бы сложно управлять?

Я начинаю понимать, как концепция MVC полезна для задач подключения к базе данных, а также для некоторых CRUD. Но я все еще не понимаю, как думать о «страницах» в MVC.

Любой совет очень ценится. Какая лучшая практика?

Answer 1

Вам не нужно иметь функцию для каждой страницы. быстрый пример, который я нашел:

<?php
//This is an example of a KISSMVC controller
//It is simply a function, which will be called by an URL such as:
//http://example.com/article/show/234
//TIP: Please assign default values to all parameters

function _show($articleid=0) {

//SECTION 1: INPUTS
//Filter, sanitize and store all inputs used by this controller
  $articleid=min(0,(int)$articleid); //zero or positive integer
  $uid = isset($_SESSION['authuid']) ? $_SESSION['authuid'] : 0;
  $someconfig = $GLOBALS['registry']['someconfig'];

//SECTION 2: LOGIC
//Call functions/objects that implement your business logic with the inputs from SECTION 1
//Data returned from your Model should not contain UI specifics (such as html code)
  $loggedinuser = new User();
  $loggedinuser->retrieve($uid);

  $article = new Article();
  $article->retrieve($articleid);

//SECTION 3: PRESENTATION
//Call the view templates with the data obtained from SECTION 2
//A change in UI should only affect code in this section
//Sometimes there is no output needed, only a header redirect is returned
  if (!$loggedinuser->hasPermission('view_article')) {
    $vars['body']='<p class="error">You have no permission to access this page!</p>';
    View::do_dump(APP_PATH.'views/mainlayout.php',$vars);
    exit;
  }

  $vars['article']=$article;
  //article template is defined in views/layout/view_article.php
  $vars['body']=View::do_fetch('layouts/view_article.php',$vars);
  View::do_dump(APP_PATH.'views/mainlayout.php',$vars);
} 

Взято из http://kissmvc.com/php_mvc_framework/code Который является реализацией PHP MVC (мне показалось, что вы работаете с PHP). Возможно, вы захотите взглянуть на их реализацию и т. Д. Это был только первый, который я нашел. Надеюсь, это поможет.

Answer 2

Если у вас есть сайт с 100 страницами, вы бы хотели, чтобы большая часть вашего контента сохранялась в базе данных.

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

http://yoursite.com/showpage?pageid=mvc
http://yoursite.com/showpage?pageid=home
http://yoursite.com/showpage?pageid=whatever

и ваш контроллер будет выглядеть примерно так:

function showpage()
{
     $post = yourframework.getmodel('post').getPost($_GET['pageid']);

     $data['title'] = "<p>" . $post.title . "</p>";
     $data['content'] = "<p>" . $post.title . "</p>";

     $this->load->view('myView', $data);
}

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

Другими словами, mvc работает так же, как vanilla php ... (но, надеюсь, выглядит немного чище)

Answer 3

Контроллеры содержат пустые функции, если на странице нет действий. Вам не нужно передавать содержимое страницы через контроллер.
Поместите все содержимое в компонент «Просмотр» текущего блока.

Answer 4

В основном у вас будет контроллер страницы для вашей модели страницы. Тогда каждая создаваемая вами страница будет иметь URL-адрес типа «/ Pages / 1», который будет перенаправлен на действие «show» вашего контроллера страницы.

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

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

index - used to show a list of all the Pages (URL like "/Pages")
show - used to show an individual Page (URL like "/Pages/1")
new - used to show a form to create a new Page
edit - used to show an edit form for a Page
create - used to actually create the new Page from the new form
update - used to actually update the Page from the edit form
destroy - used to delete a Page

Это не для всех (я не хочу превращать это в дебаты REST), но это мне очень помогает, и я думаю, что это имеет смысл, когда вы имеете дело с вещами, которые явно являются объектами, такими как Pages .

Answer 5

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

Однако при использовании MVC вы обычно хотите, чтобы Model-View-Controller имел отношение 1 к 1. Если у вас есть страница about, вам нужен контроллер специально для этого представления и действий, связанных с тем, что вы можете делать на этой странице. Ответ может заключаться в загрузке другого представления, и в этом случае другой контроллер будет реагировать на события, связанные с этим. Модель может быть общей для контроллера, но вы не хотите, чтобы какие-либо части вашего представления знали что-либо о вашей модели, иначе она сломает MVC, а контроллер - это элемент, который функционирует как клей.

Если вы действительно делаете что-то с PHP, как упоминал dtroy, это, вероятно, поможет. К сожалению, я пришел из опыта работы с MVC на iPhone. Та же концепция, хотя все вокруг.

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

Edit:

Я забыл упомянуть в ответ на ваше беспокойство, которое я не рассмотрел. Чтобы помочь, например, с «Взрывом контроллера», вы можете не обязательно создавать контроллер для каждой страницы, но по одному для каждого типа представления. Например, у вас могут быть AboutViewController и ContentViewController и, возможно, loginViewController. AboutView и LoginView будут довольно уникальными, но если вы сможете повторно использовать ваш contentView. Поэтому, если кто-то запросит что-то о «виджетах», ваш контентный вид будет просто отображать информацию о виджетах, полученных из вашей модели, и отображать ее в соответствующем месте, определенном вашим представлением. затем, когда пользователь запрашивает что-то о «зубчатых колесах», вы можете повторно использовать один и тот же ContentViewController для одинакового отображения различной информации.