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

Question

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

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

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

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

Мои чувства по поводу 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);
  }
}

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

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

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

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

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

Answer 2

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

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

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

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

Я не имею в виду, что вы должны изучать CherryPy. Я имею в виду, что простота, ясность и удовольствие от разработки с вашим собственным веб-приложением идут ДОЛГОГО пути.

---

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

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