2.1 Убить валидацию и фильтры в AR

Уже исправленные репорты или принятые предложения
Аватара пользователя
S c
Сообщения: 864
Зарегистрирован: 2012.04.11, 14:46

Re: 2.1 Убить валидацию и фильтры в AR

Сообщение S c » 2018.01.31, 15:29

zelenin писал(а):
2018.01.31, 15:25
что переусложняет код. применить разные правила валидации непосредственно в месте валидации удобнее и нагляднее.
Верно, поэтому и выбираем, где использовать yii, где AR, а где другие подходы.

chesar
Сообщения: 487
Зарегистрирован: 2013.04.10, 17:49

Re: 2.1 Убить валидацию и фильтры в AR

Сообщение chesar » 2018.01.31, 15:31

S c писал(а):
2018.01.31, 15:19
Для этого существуют сценарии
Тут я согласен с
BrusSENS писал(а):
2018.01.31, 14:59
после чего куча сценариев и правил превращается в ад. И хорошо, если только сценарии.
и надеюсь господь меня убережёт от ситуаций, когда мне достанется код со сценариями.

Аватара пользователя
S c
Сообщения: 864
Зарегистрирован: 2012.04.11, 14:46

Re: 2.1 Убить валидацию и фильтры в AR

Сообщение S c » 2018.01.31, 15:37

читайте выше, а не между строк. я не топлю не за AR, не за Yii. Сложному проекту нужен серьезный фреймворк. Пытаться везде использовать yii, чуток "подтюнив" его - не лучший вариант. Когда начинаешь сталкиваться со сложностями и недостатками AR - возможно стоит от AR отказаться в данном проекте

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: 2.1 Убить валидацию и фильтры в AR

Сообщение zelenin » 2018.01.31, 15:40

S c писал(а):
2018.01.31, 15:29
zelenin писал(а):
2018.01.31, 15:25
что переусложняет код. применить разные правила валидации непосредственно в месте валидации удобнее и нагляднее.
Верно, поэтому и выбираем, где использовать yii, где AR, а где другие подходы.
но AR != встроенная валидация/сценарии.
Поэтому имеем право говорить о выносе валидации без наездов на сам паттерн.

Аватара пользователя
BrusSENS
Сообщения: 496
Зарегистрирован: 2012.07.26, 06:51
Откуда: Новороссийск
Контактная информация:

Re: 2.1 Убить валидацию и фильтры в AR

Сообщение BrusSENS » 2018.01.31, 15:52

S c писал(а):
2018.01.31, 15:27
да, AR у нас валидирует сами данные (с дополнительной возможностью добавления клиентской валидации, путем генерации js кода на основании правил), не зависимо от формы. Причем тут форма?
Я говорю об Model (Форма - Form Model), которая прекрасно подходит для валидации.
S c писал(а):
2018.01.31, 15:27
Вам об этом и говорят, что yii и AR в частности удобен на простеньких CRUD проектах. Где начинается сложная логика - начинается АД, и поэтому придумали альтернативные паттерны и подходы. Даже возможность afterSave() - превращается в ад проекта, когда проект начинает превращаться в крупного энтерпрайз монстра.
AfterSave - Для этого лучше юзать события, а не переопределять метод.
"Энтерпрайз" не означает DDD или то, что AR использовать против религии и всех моральных норм. Да и речи не было тут про "энтерпрайз".
S c писал(а):
2018.01.31, 15:27
AR - это уже не SOLID.
Я и не предлагал сделать AR по всем буквам SOLID.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x

Аватара пользователя
BrusSENS
Сообщения: 496
Зарегистрирован: 2012.07.26, 06:51
Откуда: Новороссийск
Контактная информация:

Re: 2.1 Убить валидацию и фильтры в AR

Сообщение BrusSENS » 2018.01.31, 15:52

zelenin писал(а):
2018.01.31, 15:40
но AR != встроенная валидация/сценарии.
Поэтому имеем право говорить о выносе валидации без наездов на сам паттерн.
Да, спасибо за уточнение, именно об этом и шла речь.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x

Аватара пользователя
BrusSENS
Сообщения: 496
Зарегистрирован: 2012.07.26, 06:51
Откуда: Новороссийск
Контактная информация:

Re: 2.1 Убить валидацию и фильтры в AR

Сообщение BrusSENS » 2018.01.31, 15:56

S c писал(а):
2018.01.31, 15:37
Сложному проекту нужен серьезный фреймворк.
Тут зависит от того, что Вы подразумеваете под "сложным" проектом. На некоторых проектах и PHP может не подойти по ряду причин.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x

Аватара пользователя
BrusSENS
Сообщения: 496
Зарегистрирован: 2012.07.26, 06:51
Откуда: Новороссийск
Контактная информация:

Re: 2.1 Убить валидацию и фильтры в AR

Сообщение BrusSENS » 2018.01.31, 15:58

chesar писал(а):
2018.01.31, 15:31
и надеюсь господь меня убережёт от ситуаций, когда мне достанется код со сценариями.
Именно для того, что бы не было таких ситуаций (что бы не гневить Всевышнего :D) и предложил данный сабж.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x

noLogicOnlyWar
Сообщения: 75
Зарегистрирован: 2017.07.04, 20:53

Re: 2.1 Убить валидацию и фильтры в AR

Сообщение noLogicOnlyWar » 2018.01.31, 16:03

Обычно набор правил валидации уникален для источника данных.
Да, если говорим о валидации реквеста, правила наподобие уникальности имени - это общее правило независимо от контекста web/api/консоль. Если нужно провалидировать реквест - логично использовать форму. Если нужна целостность данных то логично валидировать в ar.

Аватара пользователя
S c
Сообщения: 864
Зарегистрирован: 2012.04.11, 14:46

Re: 2.1 Убить валидацию и фильтры в AR

Сообщение S c » 2018.01.31, 18:37

zelenin писал(а):
2018.01.31, 15:40
S c писал(а):
2018.01.31, 15:29
zelenin писал(а):
2018.01.31, 15:25
что переусложняет код. применить разные правила валидации непосредственно в месте валидации удобнее и нагляднее.
Верно, поэтому и выбираем, где использовать yii, где AR, а где другие подходы.
но AR != встроенная валидация/сценарии.
Поэтому имеем право говорить о выносе валидации без наездов на сам паттерн.
впервые с вами не соглашусь) верней соглашусь, только частично.
В предложении MF-а действительно AR не обязан включать виладацию.
Но в итоге - в большинстве реализаций AR реализуют валидацию, это уже практически стандартный подход.
php, ruby, java - посмотрел - AR реализации включают валидацию в классе.

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: 2.1 Убить валидацию и фильтры в AR

Сообщение zelenin » 2018.01.31, 18:47

S c писал(а):
2018.01.31, 18:37
zelenin писал(а):
2018.01.31, 15:40
S c писал(а):
2018.01.31, 15:29

Верно, поэтому и выбираем, где использовать yii, где AR, а где другие подходы.
но AR != встроенная валидация/сценарии.
Поэтому имеем право говорить о выносе валидации без наездов на сам паттерн.
впервые с вами не соглашусь) верней соглашусь, только частично.
В предложении MF-а действительно AR не обязан включать виладацию.
Но в итоге - в большинстве реализаций AR реализуют валидацию, это уже практически стандартный подход.
php, ruby, java - посмотрел - AR реализации включают валидацию в классе.
и? мысль-то поясните. Что означает по вашему традиционное наличие валидации внутри модели?

Аватара пользователя
S c
Сообщения: 864
Зарегистрирован: 2012.04.11, 14:46

Re: 2.1 Убить валидацию и фильтры в AR

Сообщение S c » 2018.01.31, 18:56

Мысль я описывал выше. В определенных ситуациях - удобно и быстро. Создал AR класс, есть добавление с формы, есть импорт из файла, есть добавление через API. Код для всех ситуаций одинаков - получаем массив данных ($_POST, с файла, с апи, не важно, получаем массив) - $obj->save();

Если есть ошибки - опять же имеет массив ошибок и в разном виде на разные "клиенты" их отображаем. Ну это максимально быстрый и удобный подход, согласитесь? + AR валидация еще и JS код для формы генерит (если active form используем). Да, можно на мою картинку ответить: "а если сложнее логика, разные сценарии?" (что и сделали выше) . Отвечаю: AR никогда не будет хорошим паттерном для всех условий. Но для определенных - он очень удобен. Вы согласны?
Наличие валидатора внутри модели - обечпечение логики валидации (и фильтрации) в одном месте. Что даже логично (ведь AR связан с БД, и AR данные в БД запихивает, ему и проверять валидность). И не важно откуда пришли данные, поле "name" должно быть string(255), а phone - int(N).

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: 2.1 Убить валидацию и фильтры в AR

Сообщение zelenin » 2018.01.31, 19:32

S c писал(а):
2018.01.31, 18:56
Мысль я описывал выше. В определенных ситуациях - удобно и быстро. Создал AR класс, есть добавление с формы, есть импорт из файла, есть добавление через API. Код для всех ситуаций одинаков - получаем массив данных ($_POST, с файла, с апи, не важно, получаем массив) - $obj->save();
Если есть ошибки - опять же имеет массив ошибок и в разном виде на разные "клиенты" их отображаем. Ну это максимально быстрый и удобный подход, согласитесь?
ну то есть дело в отсутствии одной строчки validate()? Я не соглашусь что это должно влиять на мое мнение.
S c писал(а):
2018.01.31, 18:56
+ AR валидация еще и JS код для формы генерит (если active form используем).
это заслуга чего? именно ВСТРОЕННОЙ валидации? если она будет вне, это не будет работать?
S c писал(а):
2018.01.31, 18:56
Да, можно на мою картинку ответить: "а если сложнее логика, разные сценарии?" (что и сделали выше) . Отвечаю: AR никогда не будет хорошим паттерном для всех условий.
мы можем его улучшить, чтобы он подходил для бОльшего кол-ва случаев.
S c писал(а):
2018.01.31, 18:56
Но для определенных - он очень удобен. Вы согласны?
безусловно. но никто и не хочет его хуже сделать. Вы считаете что вынос валидатора ухудшит ваш опыт?
S c писал(а):
2018.01.31, 18:56
Наличие валидатора внутри модели - обечпечение логики валидации (и фильтрации) в одном месте. Что даже логично (ведь AR связан с БД, и AR данные в БД запихивает, ему и проверять валидность).
это бы было логично, если производилась бы валидация по правилам, связанным именно с типами данных в БД, но т.к. там проводится еще и бизнес-валидация и фильтрация, и бизнес-кейсов может быть больше чем "сохранение модели в админке", то скорее логично, чтобы модель была валидной изначально, а валидация производилась в месте применения бизнес-правил.
S c писал(а):
2018.01.31, 18:56
И не важно откуда пришли данные, поле "name" должно быть string(255), а phone - int(N).
вот и нет. name должен быть до 255, когда идет регистрация через сайт, и равен 10 когда генерится автоматически при регистрации из мобильного приложения.

Аватара пользователя
S c
Сообщения: 864
Зарегистрирован: 2012.04.11, 14:46

Re: 2.1 Убить валидацию и фильтры в AR

Сообщение S c » 2018.01.31, 20:29

ну то есть дело в отсутствии одной строчки validate()? Я не соглашусь что это должно влиять на мое мнение.
Дело не только в строчке validate(). К примеру - где будем хранить ошибки валидации? В классе "валидаторе"?
мы можем его улучшить, чтобы он подходил для бОльшего кол-ва случаев.
Будет больше кода. Улучшать можно до безконечности ведь. Где грани?
безусловно. но никто и не хочет его хуже сделать. Вы считаете что вынос валидатора ухудшит ваш опыт?
А опыт причем? Автор хочет сделать +1 шаг к улучшению архитектуры. Так можно и от AR отойти в итоге :)
это бы было логично, если производилась бы валидация по правилам, связанным именно с типами данных в БД, но т.к. там проводится еще и бизнес-валидация и фильтрация, и бизнес-кейсов может быть больше чем "сохранение модели в админке", то скорее логично, чтобы модель была валидной изначально, а валидация производилась в месте применения бизнес-правил.
Может быть, естественно. Приложение может быть и таким - что нужно вообще от AR отказываться. Если в данном случае rules() проблемны - используйте отдельно валидатор. Никаких проблем не случится. Зачем AR в yii перепиливать из-за определенных ситуаций? В большинстве случаев вполне работает и через AR validate() подход
вот и нет. name должен быть до 255, когда идет регистрация через сайт, и равен 10 когда генерится автоматически при регистрации из мобильного приложения.
опять же. если только в этом поле дело - не проблема. Его даже и валидировать не нужно отдельно для автоматически сгенерированного, вы точно знаете что там будет уникальная строка из 10 символов. И лично вы в том же экшене (к примеру) и сгенерируете (на этом этапе она будет уникальна и 10 символов) и присвоите эту строку.

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

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: 2.1 Убить валидацию и фильтры в AR

Сообщение zelenin » 2018.01.31, 21:04

S c писал(а):
2018.01.31, 20:29
ну то есть дело в отсутствии одной строчки validate()? Я не соглашусь что это должно влиять на мое мнение.
Дело не только в строчке validate(). К примеру - где будем хранить ошибки валидации? В классе "валидаторе"?
это что, имеет значение?
S c писал(а):
2018.01.31, 20:29
мы можем его улучшить, чтобы он подходил для бОльшего кол-ва случаев.
Будет больше кода. Улучшать можно до безконечности ведь. Где грани?
почему будет больше кода? я вижу это так:
// где-то в конфиге например
$rules = [....]'
$validator = new Validator($rules);

// где то в контроллере
$errors = $this->validator->validate($model);
это одно количество кода на самом деле. почти 100% времени уйдет на описание правил валидации.
S c писал(а):
2018.01.31, 20:29
безусловно. но никто и не хочет его хуже сделать. Вы считаете что вынос валидатора ухудшит ваш опыт?
А опыт причем?
я имею в виду user experience, вы же про это говорите.
S c писал(а):
2018.01.31, 20:29
Может быть, естественно. Приложение может быть и таким - что нужно вообще от AR отказываться. Если в данном случае rules() проблемны - используйте отдельно валидатор. Никаких проблем не случится. Зачем AR в yii перепиливать из-за определенных ситуаций? В большинстве случаев вполне работает и через AR validate() подход
если большинство случаев crud, бесспорно. может стоить чуть раздивнуть рамки чтобы еще 20% сверху заиметь? не ухудшив ux программера, увеличив кол-во кейсов применения AR.
S c писал(а):
2018.01.31, 20:29
опять же. если только в этом поле дело - не проблема. Его даже и валидировать не нужно отдельно для автоматически сгенерированного, вы точно знаете что там будет уникальная строка из 10 символов
откуда я знаю? у меня api для 3rd party клиентов.
S c писал(а):
2018.01.31, 20:29
И лично вы в том же экшене (к примеру) и сгенерируете (на этом этапе она будет уникальна и 10 символов) и присвоите эту строку.
нет, снаружи придет.
Да и вообще речь конечно же не о name, а об общем.
S c писал(а):
2018.01.31, 20:29
Мы пришли к тому - "а если у нас оказалось серьезное приложение, к которому возможно и AR не подходит", но давайте использовать таки AR. Уникальные сложные случаи валидации - никто не мешает это сделать отдельно, не убиваю возможность валидировать что то простои из коробки и одинаково для всех случаев. С этого ведь и начали
плохая позиция. есть инструмент - его можно небольшими усилиями доработать. хуже не станет. станет лучше. зачем нужен другой инструмент?

Аватара пользователя
BrusSENS
Сообщения: 496
Зарегистрирован: 2012.07.26, 06:51
Откуда: Новороссийск
Контактная информация:

Re: 2.1 Убить валидацию и фильтры в AR

Сообщение BrusSENS » 2018.01.31, 21:56

S c писал(а):
2018.01.31, 20:29
А опыт причем? Автор хочет сделать +1 шаг к улучшению архитектуры.
Улучшение архитектуры приложения путём предложения по улучшению библиотеки для работы с БД? Фреймворк === архитектура?
S c писал(а):
2018.01.31, 20:29
Так можно и от AR отойти в итоге :)
Не поверите, так можно и от PHP отойти, если того потребует проект.
P.S.: Вам Zelenin наверное даже подтвердит, он вроде не так давно делал проект на Go.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x

Аватара пользователя
S c
Сообщения: 864
Зарегистрирован: 2012.04.11, 14:46

Re: 2.1 Убить валидацию и фильтры в AR

Сообщение S c » 2018.01.31, 22:40

Так о чем речь то? есть же валидатор от model/form, используйте его. используйте его отдельно, исспользуя AR rules()
если большинство случаев crud, бесспорно. может стоить чуть раздивнуть рамки чтобы еще 20% сверху заиметь? не ухудшив ux программера, увеличив кол-во кейсов применения AR.
Речь о том что бы убить\убрать\вынести validate() в AR (который полезен). Этого делать не стоит.
Добавить новый сервис Validator - та без проблем. Хоть в рамках yii, хоть самому у себя в проекте.
плохая позиция. есть инструмент - его можно небольшими усилиями доработать. хуже не станет. станет лучше. зачем нужен другой инструмент?
как доработать? убрать удобный функционал? вынести его?

Аватара пользователя
S c
Сообщения: 864
Зарегистрирован: 2012.04.11, 14:46

Re: 2.1 Убить валидацию и фильтры в AR

Сообщение S c » 2018.01.31, 22:44

BrusSENS писал(а):
2018.01.31, 21:56
S c писал(а):
2018.01.31, 20:29
А опыт причем? Автор хочет сделать +1 шаг к улучшению архитектуры.
Улучшение архитектуры приложения путём предложения по улучшению библиотеки для работы с БД? Фреймворк === архитектура?
S c писал(а):
2018.01.31, 20:29
Так можно и от AR отойти в итоге :)
Не поверите, так можно и от PHP отойти, если того потребует проект.
P.S.: Вам Zelenin наверное даже подтвердит, он вроде не так давно делал проект на Go.
Я вам не отвечаю, потому что какой-либо конкретики у вас нет вообще. набор слов пишите, извините. Я тоже писал проект на GO, и что с этого?
По теме что? валидируйте ваш объект спокойно отдельно, вам это сразу предложили. И в разных местах - используйте свои правила. Без сценариев и прочего. Рабочий ведь вариант. Убирать встроенный validate() в AR - не стоит, ибо в простейших случаях - это самый быстрый, простой и удобный функционал.
Используйте Model, FormModel (или что то подобное), напишите на коленке класс Validator. И Будет именно то, что вы хотите

Аватара пользователя
S c
Сообщения: 864
Зарегистрирован: 2012.04.11, 14:46

Re: 2.1 Убить валидацию и фильтры в AR

Сообщение S c » 2018.01.31, 22:47

сорри, оффтоп: Как вы отдельные куски мои цитируете, с ником?)

Аватара пользователя
BrusSENS
Сообщения: 496
Зарегистрирован: 2012.07.26, 06:51
Откуда: Новороссийск
Контактная информация:

Re: 2.1 Убить валидацию и фильтры в AR

Сообщение BrusSENS » 2018.01.31, 22:57

S c писал(а):
2018.01.31, 22:40
Так о чем речь то? есть же валидатор от model/form, используйте его. используйте его отдельно, исспользуя AR rules()

Речь о том что бы убить\убрать\вынести validate() в AR (который полезен). Этого делать не стоит.
Добавить новый сервис Validator - та без проблем. Хоть в рамках yii, хоть самому у себя в проекте.

как доработать? убрать удобный функционал? вынести его?
Убрать его из AR в угоду строгости. Часто встречаются проекты, где от этого приходится избавляться, хотя тем, кто это писал понравилось. Просто же. Yii многое позволяет делать, с этим и есть предложение бороться. PHP и веб девелоп вырос и накладывает определенные рамки на разработчика. Пора и Yii внести строгости.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x

Ответить