V часть в модели MVC применительно к CMS

Question

С CMS (PHP / MySQL), которая становится все больше и больше, а ее код сложнее поддерживать, я думаю о применении модели MVC, чтобы сделать ее более понятной и прозрачной. Я немного разгадал эту тему, и, думаю, у меня все получилось, за исключением части просмотров. Вот что я имею в виду:

index => controllers <=> models
         controllers  => views

index.php, который выступает в качестве основного контроллера (маршрутизатора) и создает экземпляры классов контроллеров на основе параметров в URL. Контроллер классов общается с моделями классов для обновления и извлечения информации в / из базы данных. И после этого контроллер обеспечивает отображение представления (в форме шаблонов) и принимает обработанные данные для отображения. Однако ...

Идея состоит в том, чтобы перенести всю логику с вида на контроллер, верно? Или, по крайней мере, далеко от поля зрения - чтобы не было обсуждения жирных / тощих контроллеров / моделей. Но каким бы образом я ни смотрел на это, мне все равно нужны динамические представления, и для этого также потребуется некоторая логика. Например, отображение определенных параметров для определенных пользователей в зависимости от их уровня и прав (обновление, обновление / удаление и т. Д.). Так что это сводится к заявлениям if / else и тому подобным вещам. Это нормально? И если да, то сколько из этой «простой» логики «разрешено»? Моя точка зрения доходит до того, что другой шаблон начинает приобретать больше смысла (например, profile_view и profile_edit).

Еще один простой пример. Скажем, один пользователь может видеть 5 из 10 полей профиля, а другой - 10/10. Должен ли я получить всю информацию для всех 10 полей через контроллер и определить в представлении, отображать ли ее? Или перенести решения такого рода в контроллер, а также получить информацию для 5 или 10 полей и отобразить только доступные поля в представлении на основе переданной информации? Потому что во многих ситуациях гораздо проще собрать все данные и игнорировать некоторые из них, в отличие от незнания того, что доступно, и необходимости постоянно проверять это.

Answer 1

В моем понимании и применении MVC контроллер содержит бизнес / приложение логика, но представление может содержать презентационная логика. Вы хотите, чтобы ваши представления были максимально простыми и конкретными, но вы не хотите генерировать HTML (например) в вашем контроллере и просто отображать его в представлении.

Answer 2

"Так что все сводится к операторам if / else и подобным вещам. Это нормально?"

Да.

"сколько из этой" простой "логики" разрешено "?"

В шаблонах представления должны присутствовать простые if-else и простые циклы.

Нет расчетов. Нет логики обработки форм. Ничего из этого.

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

[Если у вас есть терпение прочитать документацию Django на основе Python, вы можете увидеть, что следует разрешить. Возможно, есть некоторые PHP-фреймворки с похожей философией.]

«Скажем, один пользователь может видеть 5 из 10 полей профиля, а другой пользователь 10/10»

Есть несколько подходов.

1. Два разных шаблона страницы, показывающие одни и те же базовые данные. Вы получаете все, но выберите шаблон, подходящий для пользователя.

2. Один сложный шаблон, показывающий вариант базовых данных. Вы выбираете все, предоставляете подходящие флаги и отправляете в шаблон, который использует операторы if-side-side.

Что "лучше"? Зависит от вашего аппетита к сложным страницам. Лично я предпочел бы иметь две простые страницы и использовать какое-то наследование, чтобы выделить общие черты. Мне не нравятся операторы if, они являются причиной проблем в будущем. OTOH, некоторые люди любят операторы if и не обращают внимания на их сложность.

Answer 3

Во второй пример: не передавайте все 10 полей только видимым, фильтруйте невидимые элементы в контроллере и сохраняйте представление простым, насколько это возможно.