PHP MVC (без фреймворка), должен ли я вызывать множество методов в моем контроллере или модели?

Question

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

Небольшая справочная информация о моем приложении:Я использую smarty в качестве своего докладчика и объектно-ориентированный подход.Кажется достаточно простым, но я пытаюсь разобраться в вездесущем вопросе "что такое модель".

Если я взгляну на некоторые учебные пособия и фреймворки, они, похоже, рассматривают модель строго как класс, который наследует методы DAL от абстрактного класса, с небольшим дополнением, определенным в самом классе, поскольку ваши потребности в данных отличаются от объекта к объекту.Например, я мог бы увидеть что-то вроде $ProductModel->get(5), которое возвращает массив из 5 продуктов из базы данных.Ну и что, если мне нужно запросить несколько моделей?Должен ли я хранить все данные в контроллере или массиве и передавать их в представление?Затем, если я динамически вызываю свой контроллер, как я могу сохранить уникальные для контроллера данные, необходимые для отображения представления?Это кажется плохим, особенно потому, что затем мне приходится передавать такие вещи, как "controllerName", "controllerData", и мой метод View:: render() сильно раздувается параметрами, если я не передам сам контроллер.Может быть, я здесь чего-то не понимаю.

Допустим, я хочу создать логин, который запрашивает таблицу users.Login - это модель или контроллер, в зависимости от определенных реализаций, которые я видел в Интернете.Некоторые реализации (я назову этот метод 1) создают LoginController с методом login(), который может выполнять сравнение $ _POST и того, что возвращается из экземпляра модели пользователя $user-> get(1), чтобы увидеть, проверен ли пользователь.Или, может быть, login() может быть методом в контроллере по умолчанию.С другой стороны, реализация (метод реализации 2), которая больше напоминает подход Joomla, создала бы модель входа в систему и объявила бы все действия внутри нее.Тогда любые данные, которые необходимо присвоить представлению, будут возвращены из этих методов.Таким образом, login-> login() на самом деле проверит post, посмотрит, есть ли совпадение и т.д.Кроме того, модель пользователя, вероятно, будет создана внутри этого метода model.

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

Мои чувства по поводу 2:Это не требует выполнения действий, которые не являются методами модели.Если я хочу перейти в корневой каталог своего сайта, мне нужно создать индексную модель или что-то еще, что кажется излишним, чтобы иметь модель, которая передает данные в представление.Кроме того, это, похоже, не очень популярный подход.Однако мне это нравится больше, потому что я могу просто выполнить View ::render(mymodel-> func()) и убедиться, что данные будут переданы обратно именно так, как мне нравится, без необходимости портить мой контроллер кодом, объединяющим тысячу результатов запроса вместе.

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

Answer 1

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

Для контроллера входа в систему я мог бы создать что-то подобное...

URI сообщения: http://example.com/login/authenticate

LoginController extends ParentController {
  public function authenticate() {
    $credential_model = $this->getModel('credentials');
    // Obviously you should sanitize the $_POST values.
    $is_valid = $credential_model->isValid($_POST['user'], $_POST['email']);
    $view = $is_valid ? 'login_fail.php' : 'login_success.php';
    $data = array();
    $data['a'] = $a;
    // .. more vars
    $this->view->render($view, $data);
  }
}

На мой взгляд, данные всегда должны поступать из model -> controller -> view, поскольку это имеет наибольший смысл (данные, манипуляции, вывод).Представление должно иметь доступ только к тому, что ему предоставлено контроллером.

Что касается этого...

Затем, если я динамически вызываю свой контроллер, как я могу сохранить уникальные для контроллера данные, необходимые для отображения представления?

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

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

Answer 2

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

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

Если один из способов «неправильно», то вы узнаете через опыт, а не кто-то другой, говорящий вам. И вы узнаете всю ситуацию намного лучше, и точно знаете, почему один путь лучше.

Что помогло мне, когда я писал свои собственные рамки в PHP, было достаточно странно, Мошенник. Отказ Он сделал концепцию объектно-ориентированного веб-приложения настолько простым и очевидным, и мне очень понравилось использовать его так много, что смоделировал основную структуру моей рамки PHP, чтобы имитировать Cherrypy.

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

---

Если бы я мог дать один специфический совет, я бы сказал, попробуйте избежать raptyping код; Напишите свой код, чтобы повторно использовать как можно больше ситуаций. Это будет не только хорошо для вашего приложения, но для будущих приложений вы можете написать или работать.

Вы можете проверить Эрик С. Рэймонд Правила для программирования Unix. Отказ Я думаю, что они определенно применимы здесь.