Где Вы принимаете и обрабатываете $_POST запросы?

Question

[bedolazhka]

Ну вот читаю очень часто: логика не должна содержаться в контроллере.

1. Ну и нажал я кнопку и где мне хотя бы принять и обработать это нажатие, чтобы вызвать модель - это ведь логика: проверить нажатие кнопки и то что методом POST проверить пришло.

2. Ну а если вот вынес я в модель проверку эту и работаю в методах сразу с полученными POST данными, но мне пишут, что эти данные нужно передавать в методы параметрами, потому что мало ли этот метод нужен там где-то ещё будет)))) Так если я в модели крнструктором принял их или в методе принимаю, то как я их в метод передам? Из контроллера при вызове метода модели, где эти POST данные нужны? Так это же логика: я сначала в контроллере должен принять, проверить и её нельзя в контроллер :)

Кто-то может точку поставить, чтобы не дёргаться.

Comments

[Дмитрий]

Ну вот читаю очень часто: логика не должна содержаться в контроллере

Имеется ввиду логика вычислений, параметры как раз в контролере и считываются(кроме тех, что считывает роутер) и дальше передаются в сервисы. В модели логика тоже не должна содержаться.

А вообще если не отзывается прочитанное - просто забейте, мало ли кто что в интернете пишет.

[Дмитрий]

Вечер добрый.
Посмотрите этот курс. Возможно Вам поможет.

[Максим Федоров]

Валидация может быть и до контроллера — провалидировать реквест
Валидация может быть и в моделе (модель валидации). Модель — очень емкая штука

Есть такое понятие — сквозная функциональность. Валидация относится как раз к таковой. Это одна из причин появления АОП (аспектно-ориентирвоанное программирвоание) как надстройка над объектно-ориентированным и процедурным программированием. Это причина появления аннотация в языках или их иммитация — чтобы не засорять основной код слоев и "как бы между прочим" выполнять... Это валидация, проверка прав, кеширование

де Вы принимаете и обрабатываете $_POST

Лучше не работать с голыми глобальными массивам, а лучше работать через обертку в виде Request/Response объектов. Так вы сможете абстрагироваться от работы с сервером — сможете тестировать, валидировать, изменять реквест по вашим правилам до того, как попадет в экшн, сможете авторизовывать и чистить... крч одни удобства

обработать это нажатие <...> это ведь логика

Модель — это бизнес-логика, так если копнуть — все является логикой в прогграммировании, слишком абстрактное это слово...

Нажатие если обрабатывать — это одно ,
а вот если обработать запрос на кредит, или запрос на доступ к панели, или запрос оплатить товар — это уже дело контроллера.

[bedolazhka]

Дмитрий, так у меня, например, в модели метод валидации - это же логика и валидатор врзвращает там к примеру true, я потом в контроллере проверяю, если валидатор ответил true, то запускаем метод модели там к примеру запись в БД - это же логика: проверить ответ валидатора.

[bedolazhka]

Дмитрий,

мало ли кто что в интернете пишет

так сбивают же такие посты, хочется доверять, так считается, что это мнение специалистов, а на поверку просто личное мнение кого-то там

[bedolazhka]

Максим Федоров, валидатор в модели, где до вызова метода валидации проверить нажатие кнопки post формы?

[Евгений Ромашкан]

Кто-то может точку поставить, чтобы не дёргаться

bedolazhka, Валидируйте DTO до контроллера в резолверах(argument resolvers). Модель валидировать не нужно. Модель свои переходы состояния должна ограничивать на уровне интерфейса (никаких геттеров/сеттеров). Не все ограничения можно выразить на уровне интерфейса в PHP, и при невалидном для модели значении переданном в её метод, она может кидать исключение.
Модель ничего про реквест знать не должна. Точка.

[Максим Федоров]

bedolazhka, что вы к кнопкам привязались... я так и вижу, как предприниматель создавая свой настоящий магазин зацикливается не на продаже (запросе на покупку), а на том, как руку вытягивает продавец.
Руку конечно нужно вытянуть — но это к прцоессу построения магазина относится постольку поскольку...
контроллер-модель — это про процессы, про устройство магазина (не про руки), а про отношения и процессы

предыдущий комментарий дополнил для понятности

[bedolazhka]

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

[bedolazhka]

Максим Федоров,

if (filter_has_var(0, 'go')) { // логика - нажали кнопку методом POST
    $model = new Model();
    if ($model->validator() === true) { // логика - валидация прошла
        $model->go(); // что-то делаем в БД, если ещё в метод передать имя таблицы, то тоже становится похожим на логику
    }
    $model->error;
}

так нельзя же логику в контроллер.

[Дмитрий]

bedolazhka,

так сбивают же такие посты, хочется доверять, так считается, что это мнение специалистов

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

[Дмитрий]

bedolazhka, проверьте в контроллере $request->isPost()

[Дмитрий]

Максим Федоров, такую портянку можно и в ответ было запилить

Answer 1

[Vitsliputsli]

В том контексте, где вы читали, имелась ввиду бизнес-логика. MVC - это по-сути деление кода на логические слои "ввод", "обработка", "вывод". Попробуйте, представить, что у вас взаимодействие пользователя не только через web, но и как-то еще, какое-нибудь api, или даже командная строка. Чтобы не дублировать код, вы выделите какую-то общую часть, это и будут модели, а различия ввода уйдут в контроллеры, и там уже в них будете обрабатывать http-запросы или аргументы командной строки.
Но не нужно мои слова понимать буквально, как ту статью. К примеру, я не имел ввиду, что api - это только контроллеры, в какой-то момент вы решите что нужны собственные модели для api, да и вообще нужно выделить его в отдельный модуль.
Схема MVC, как и паттерны проектирования - это способы управления сложностью. В данном случае мы боремся с сильным зацеплением, т.е. зависимостью классов друг от друга во многих частях. Чем меньше таких зависимостей, тем проще будет расширять код. Писать api к правильно разделенному по mvc коду достаточно легко, но если везде будут произвольно натыканы обращения к данным post-запроса, то все эти куски придется переписывать. Продумывайте как будете расширять проект.