Laravel А что greater than нету?

[Adelf]

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

К Eloquent она не прибита вроде. Она напрямую в базу идёт.

 

[fixxxer]

Ой... Еще хуже.
Честно говоря, я это ни разу не использовал, так что не помню.

 

[Вурдалак]

Указывать таблицу, где хранятся сущности в правиле валидации?

Я хочу обратить внимание, что я говорил про обращение к query services.
Coupling с именами таблиц — это несколько иная проблема, которая прямого отношения к unique/exists не имеет.
Вместо имени таблицы там может быть алиас хендлера, который делает что-то типа

'user_exists' => function (int $id) {
    try {
        $this->userQueryService->find($id);

        return true;
    } catch (UserDoesNotExist $e) {
        return false;
    }   
},

Изначально же речь шла про то, насколько я понял, что unique/exists в форме — что-то концептуально неверное.

 

[Adelf]

Понятно. Концептуально... мне не нравится тем, что эта валидация формы - концептуально такая же вещь как клиентская валидация. В нормально организованном приложении эта валидация фактически дублируется внутри домена. Не дадут создать DDD-сущность с неверными свойствами и т.д.
Поэтому данная валидация - просто чтобы удобно отфильтровать данные с красивыми сообщениями над каждым неправильным полем(тоже самое, что клиентская валидация). И для этой штуки... как-то не очень тратить ресурсы на создание такой правильной вещи, которую ты описал(c QueryService). Все равно юзер увидит нормальное сообщение.

 

[Вурдалак]

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

Тебе это не нравится, так как валидация формы серверная. Если бы она была на стороне JS, то запрос на проверку уникальности перед отправкой ты бы воспринимал нормально

 

[Adelf]

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

По первому абзацу - много думал. Пока не знаю что сказать

 

[fixxxer]

Исключение типа EmailIsNotUnique при такой реализации (без транзакций и прочих селект-фор-апдейтов) все равно надо корректно обрабатывать и отдавать наружу как нормальную ошибку валидации ввода.
Так что особого смысла не видно, разве что там посередине дофига тяжелой фигни, которую зря делать не хочется.
А сообщение в лог - ну это смотря как реализовать, можно сделать insert ignore и проверять affected rows, например.

 

[grigori]

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

Можно отвлечься от синтаксиса Ларавель и посмотреть с такой стороны: есть целостный набор данных - ввод, и есть вычисления, которые надо с ними провести - то есть, объект с методами. Инкапсуляция.
Размазывать однородные вычисления над одним набором данных по разным участкам приложения - нарушение инкапсуляции.

 

[Вурдалак]

Можно отвлечься от синтаксиса Ларавель и посмотреть с такой стороны: есть целостный набор данных - ввод, и есть вычисления, которые надо с ними провести - то есть, объект с методами. Инкапсуляция.
Размазывать однородные вычисления над одним набором данных по разным участкам кода - нарушение инкапсуляции.

Ты ошибаешься в том, что считаешь эти «вычисления» одними и теми же.
Форма не валидирует модель.
Форма валидирует собственное состояние.
А модель валидирует своё.
И эти правила могут отличаться вполне законно.

 

[grigori]

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

Какая у формы может быть собственная логика, не связанная с бизнес-логикой?
Равенство полей паролей, длина строки, размер изображения - это технологические ограничения, которые связаны не с формой, а с реализацией стека php/mysql. Стоит ли считать их "логикой формы", состоянием? На состояние не похоже, но с доменом это не связано.

 

[WMix]

Размазывать однородные вычисления над одним набором данных по разным участкам приложения - нарушение инкапсуляции.

так - форма проверяет что сумма перевода меньше чем денег на счете.

 

[grigori]

так - форма проверяет что сумма перевода меньше чем денег на счете.

да, это валидация с учетом бизнес-логики: проверка аутентифицированности, наличия счета, состояния счета, значения МФО банка получателя

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

 

[Вурдалак]

Какая у формы может быть собственная логика, не связанная с бизнес-логикой?

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

 

[grigori]

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

Да, логика отображения и валидация на клиенте не имеет никакого отношения к валидации данных в PHP-приложении на сервере, и в контексте php я это не рассматриваю.
Я пишу про валидацию данных, которые получены php-скриптом.

не смог удержаться и добавил ссылку )))

 

[WMix]

и инжектить в форму модель

 

[grigori]

@WMix, более того, получается, что для валидации формы (в PHP, напоминаю) логично создать специальный класс, который относится к модели, его объект получает данные запроса, и в него инъектится, например, фабрика валидаторов, а в этом классе прописаны правила валидации

 

[Вурдалак]

Да, логика отображения и валидация на клиенте не имеет никакого отношения к валидации данных в PHP-приложении на сервере, и в контексте php я это не рассматриваю.

Это не имеет значения, т.к. тоже самое можно сказать и про серверную валидацию формы.
Форма может оставаться такой, какая есть по разным соображениям, а модель может сильно меняться.

Нужно мыслить use case'ами, а не формами.
Если ты переключаешь <select> из статуса «Требует подтверждения» в «Подтверждён» в форме редактирования пользователя, то с точки зрения бизнеса ты поменял не число, ты выполнил команду «Подтвердить пользователя».
Ты же мыслишь именно как «поменять число», пытаешься связать модель и форму.
Я же могу запилить отдельную кнопку «Подтвердить пользователя» и это будет ровно то же самое бизнес-действие, вопрос интерфейса.
Ты же запилишь новый код для смены статуса, потому что ты рассматриваешь сущность как пачку данных, с которой можно делать что угодно.
Твои формы — это классический пример https://en.wikipedia.org/wiki/Magic_pushbutton.

 

[grigori]

Я мыслю категорией "внешний интерфейс", который известен и меняется редко относительно кода серверной и клиентской части.
Определена не кнопка и не форма, а протокол - url, параметры, ответ, коды ошибок.
Я отношусь к HTTP как к подмножеcтву REST, который, в свою очередь, является подмножеством RPC - вызов удаленных процедур на сервере по известному протоколу.
Параметры вызова могут прийти в SOAP, JSON, Base64, mime, urlencode, WAMP, protobuf.
"Форма" - элемент пользовательского интерфейса, а серверный код оперирует массивом данных в параметре функции. Я говорю о том, что валидировать надо сами данные, которые явно можно инкапсулировать с обработчиком-валидатором.

> пытаешься связать модель и форму
да, я нормально отношусь к парадигме data binding.

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

 

[Adelf]

да, я нормально отношусь к парадигме data binding.

Я писал WPF приложения в C#. Вот только на форму там биндят специальные ViewModel. И прямого отношения к модели они не имеют. Они вообще из UI слоя.
Напрямую биндить модель и форму привыкли те, кто писал слишком много CRUD приложений.

 

[grigori]

@Adelf, то есть ты тоже опять не читаешь то, что комментируешь, понятно.
примеры популярного сейчас "data binding" - это Angular, Knockout, React, Ember, в них связываются данные не между сервером и клиентом, а внутри клиента, в то время как для связи с сервером определяется протокол, в результате вызовов по которому и обновляется связанная модель на клиенте
а то, что тебе C# тебе генерит JS - это уже твой выбор