Может ли модель работать с массивом _POST и записывать данные в сессию?

Question

[Dreaded]

В модели пользователя я описываю метод регистрации. Могу ли я из этого метода напрямую взаимодействовать с массивом $_POST`, и при удачной регистрации записать данные в сессию?

Или же мне нужно в контроллере передать в метод регистрации данные формы , и получив результат выполнения регистрации записать данные в сессию?

И еще вопрос: кто должен заниматься валидацией данных - модель или контроллер? Я сделал валидацию данных в сеттерах модели, т.е. перед тем как записать какое то свойство пользователя, будь то имя или email, в соответствующем сеттере данные сначала проходят проверку. Это приемлемо?

Answer 1

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

• в модель должны попадать чистые данные (то есть таки да - -в контроллере)
  
• вообще с голым _POST не нужно в 2018 году работать, посмотрите это видео: https://vk.cc/8dAijK
  
• валидацией может заниматься модель, но в данном случае МОДЕЛЬ ВАЛИДАЦИИ, а не модель сущности,
  модель -- это целый слой, а не конкретный класс или вид классов, это и сущности и сервисы и валидация и т.д....
  

POST в моделе
Не правильно работать с _POST в моделе, тк модель -- по сути синоним вашего бизнеса, бизнес модель, мне кажется странным было бы, если в магазине были бы продавцы, товары, операции дать денег и взять сдачу, данные (купюра, скидка)
и тут же некий _POST запрос (ну или некая звуковая информация для операций (с битрейтом и частотой:):) мне кажется в бизнес-процесс должно попадать число или купюра, которое обработает некий контроллер (глаз, ухо и продавец в целом как валидатор)

Валидация в сеттере
По поводу сеттеров и валидации -- тоже плохо
Купюра должны быть проверена в момент ее передачи, а не когда вы уже дали товар, посчитали сдачу, напечатали чек).. аналогия может быть немного не точной, но понятен принцип -- не в сеттере :)

Ну или как пример -- договор между юрлицами, когда вы договорились и заполняете договор, для подписей (по сути сеттер ваш абстрактный) вы УЖЕ ДОЛЖНЫ были проверить контрагента и условия этого самого договора

Польза абстракций

Мне кажется так получается гораздо сложнее чем просто в каждом сеттере прописать валидацию. В общем, объясните, пожалуйста, как это реализовать и в чём плюс такого подхода

Если каждый раз писать валидацию, то нужно каждый раз ее писать :)
Если вынести это в отдельную прослойку, то за валидацию будет отвечать отдельный слой, которому вы просто скармливаете поля и их правила -- это упрощает работу с задачей "валидировать" -- вы можете этот слой чинить и усложнять, а сеттеры будут чистыми и не будет копипаста со всеми проблемами -- дублирваоние (забыл, не углядел и прчоее)

Смотрите как валидация делается в Ларавел:

public function rules()
    {
        return [
            'name' => 'required|string|max:255',
            'email' => 'required|string|email|max:255|unique:users',
            'password' => 'required|string|min:6|confirmed',
        ];
    }

Comments

[Dreaded]

Максим Федоров , видео интересное, обязательно его посмотрю, но что вы имеете ввиду под "голым _POST"?
Могли бы в общих чертах рассказать как правильно спроектировать модель валидации?
Я сейчас представил себе это так: 1 класс, в котором описаны все статичные методы валидации(а их кстати может быть много), это и валидация текста(при чём в разных местах он может соответствовать разным регуляркам) и валидация файлов(к которым опять же могут быть разные требования), почты, и т.д.
И соответственно в сеттере какой-либо сущности перед тем как записать данные в свойство мы вызваем Validation::validationParam($param). Так что ли?
Мне кажется так получается гораздо сложнее чем просто в каждом сеттере прописать валидацию.
В общем, объясните, пожалуйста, как это реализовать и в чём плюс такого подхода.

[Dreaded]

Максим Федоров , пока писал комментарий - вы уже отредактировали пост :)
Я примерно понял(надеюсь :) ) мысль которую вы пытаетесь донести. Т.е. в модель уже должны попадать полностью готовые для работы данные ? Значит сбор, компоновка и валидация данных должна происходить в контроллере? Соответственно методы валидации можно определить и в базовом контроллере а потом наследоваться от него? И еще немного смущает, что это может нарушить концепцию "тонкого контроллера".

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

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

Dreaded, по валидации ответил немного -- еще раз отредактирваол вопрос

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

Dreaded,

И еще немного смущает, что это может нарушить концепцию "тонкого контроллера".

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

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

контроллер всего лишь готовит очищенные данные, вызывает нужный сервис и все -- тоньше и не придумать

[Dreaded]

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

class Validation extends Model
{
    public static function validateUserName($username)
    {
         //validation return true/false
    }

    public static function validateEmail($email)
    {
         //validation return true/false
    }

    public static function validateFile($username, $params)
    {
         //validation return true/false
    }
}

class User extends Model
{
    public function register($data) 
    {
        $this->setName($data['userName']);
        $this->setEmail($data['email']);
        return  ($this->save()) ? true :  false;
    }
}    

class RegistrationController extends Controller
{
    $formData = $_POST;
    if  (Validation::validateEmail($formData['email']) === false) {
        return false
    }
    if  (Validation::validateUserName($formData['userName']) === false) {
        return false
    }
    $user = new User();
    if ( $user->registration($formData) === true) {
        $_SESSION = get_object_vars($user);
        return true;
    } else {
        return false;
    }
}

[ozornick]

Dreaded, в целом это правильный путь. Только class Validation extends Model
наследовать от базового валидатора.
Для понимания разделения я прокручиваю ситуации "а что, если..." контроллер будет общаться через AJAX? И придется все проверки проводить заново в новом классе. При валидации в модели (модель = сервисный слой) как раз таки получается тонкий контроллер.

class AjaxController
{
    public function register()
    {
        $data = json_decode($_POST);
        $model->register($data);
    }
}

class UserController
{
    public function register()
    {
        $model->register($_POST);
    }
}

class UserModel
{
    public function register($data)
    {
        if (UserValidator::check($data) === true) {
            $db->insert($data);
            return true;
        }
        return false;
    }
}

[Dreaded]

ozornick, ага, суть я примерно понял. Но только не могу понять, почему всё таки валидатор это модель а не контроллер? Ведь по сути он в себе не хранит каких то данных, а нужен лишь для того что бы передать данные в другую модель, что больше похоже на функционал контроллера, или вообще условно говоря какого то хелпера.

[ozornick]

Dreaded, вообще никто не ограничивает в самостоятельном выборе логики. Можно проводить валидацию в контроллере. Но как я показал выше, неудобно в дальнейшем расширять функционал. Надо дублировать код.
P.S. Сам немногим дальше ушел в этом вопросе =) Далее еще много чего непонятного.

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

Dreaded, валидация относится к бизнес-логике -- для вашей логики важно, это цифра или что-то еще

контроллер можно заменить или несколько контроллеров будет с одним слоем модели работать, везде валидировать будете? :)

[Dreaded]

Максим Федоров , ozornick , я попытался собрать воедино те советы что вы мне дали, и реализовал процесс регистрации следующим образом(данные формы отправляются ajax'ом) : AjaxController, Model User, Model Validator. Если найдется время, могли бы вы дать комментарий - уловил я общий смысл или нет?)

[dmitriy]

//UserController::add

$user = $userRepository->buildFromArray($_POST);

$userValidation = new UserValidation($user);

if(!$userValidation->isValid()){
throw new ValidationErrorException($userValidation->getErrors());
}

$userRepository->save($user);

[Dreaded]

diamond, это , типа идеал тонкого контроллера к которому нужно стремиться?

[dmitriy]

это ответ И еще вопрос: кто должен заниматься валидацией данных - модель или контроллер

а тонкий контроллер это :

//UserController::add

try{

$userService->add($_POST);

}
catch(ValidationErrorException){

return new Response("Ошибка валидации");

}

return new Response("Успешно!");

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

diamond, только в примере с хорошей архитектурой (а в ваших примерах она хорошая достаточно) негоже _POST использовать, а некий ResponseInterface :)

[dmitriy]

да верно,
$userService->add($request);
но если еще в сторону улучшения
$userDTO = DTO/UserRequest::build($request);
$userService->add($userDTO);

[ozornick]

Dreaded, абстрагируйтесь от модели как одиночный компонент. diamond, ответил как можно сократить еще. Но требуется переосмыслить логику всего приложения, так как появляются сервисы, репозитории.

Answer 2

[Yan-s]

Модель не должна зависеть от способов ввода/вывода. Она не должна знать ничего о способе предоставления (веб, декстоп, ...) приложения в котором она работает. Сейчас вы хотите, чтобы она обрабатывала HTTP запрос, а завтра вам понадобится предоставить возможность запускать эту же логику командой из консоли, например.