MVC модели в PHP - правильный порядок и разделение процессов

Question

Мне нужна помощь в разъяснении правильной структуры и последовательности процессов для приложения MVC в PHP.

Я думаю, что я неправильно понял концепцию, потому что в настоящее время большая часть моей обработки выполняется (или, по крайней мере,инициировано) Взгляды.- Я унаследовал этот образ мышления от компании, в которой я работаю, но теперь я не уверен, что они правильно понимают модель MVC!

Посмотрев на нее еще раз, я думаю, чтоПроцесс должен быть следующим (очень просто):

• Действия пользователя отправляются на контроллер
• Контроллер обрабатывает эти действия с использованием любых требуемых моделей
• Контроллерзатем создает соответствующий вид и передает ему необходимые данные
• Вид отображает страницу пользователю

---

У меня также возникают трудности с выбором, должен ли вид отображатьдаже иметь какие-либо реальные функции или нет.

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

---

Другой вопрос заключается в том, передает ли контроллер контроллер модели ине имеет ничего общего с фактическим DBconn (так что Модель действует как Bouncer на дверях ночного клуба DB, а нас нет в списке) ИЛИ контролер «владеет» DBconn и просто предоставляет его модели, когдаэто нужно?

Буду очень признателен за любую помощь и совет, которые кто-либо может предложить.

Спасибо

edit - я нашел это полезно!

Answer 1

Ваши маркированные предположения верны :).Основная идея MVC заключается в слабой связи и взаимозаменяемости между компонентами.

Чтобы ответить на ваши вопросы:

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

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

Я действительно рекомендую взглянуть на фреймворки, которые реализуют MVC, чтобы увидеть, как они это делают.Особенно Spring - даже если вы не человек Java, реализация очень чистая - Rails, Symfony.Для чего-то более экзотического взгляните на Джанго.

Answer 2

Я отвечу на два ваших последних вопроса:

1) Представления должны иметь базовые возможности вывода, например экранирование значений, чтобы избежать проблем с безопасностью или отображение HTML-таблицы, начиная со списка объектов. Другая ответственность может заключаться в переводе меток и других константных значений (например, у вас может быть $ this -> _ ('Your label'), где функция _ ($ val) - это функция, включенная во все ваши классы представления, которая переводит строки, начинающиеся с из файла CSV).

2) В зависимости от сложности приложения у вас может быть два подслоя в слое модели. Верхний слой - это классическая модель с функциональностью ваших сущностей. Нижним уровнем является связанный класс модели ресурсов, который выполняет операции с БД. Вы также можете иметь один слой с вашими моделями, который реализует шаблон DAO. В любом случае, контроллер не должен иметь ничего общего с подключением к БД.