Верно, поэтому и выбираем, где использовать yii, где AR, а где другие подходы.
2.1 Убить валидацию и фильтры в AR
Re: 2.1 Убить валидацию и фильтры в AR
читайте выше, а не между строк. я не топлю не за AR, не за Yii. Сложному проекту нужен серьезный фреймворк. Пытаться везде использовать yii, чуток "подтюнив" его - не лучший вариант. Когда начинаешь сталкиваться со сложностями и недостатками AR - возможно стоит от AR отказаться в данном проекте
Re: 2.1 Убить валидацию и фильтры в AR
но AR != встроенная валидация/сценарии.
Поэтому имеем право говорить о выносе валидации без наездов на сам паттерн.
- BrusSENS
- Сообщения: 565
- Зарегистрирован: 2012.07.26, 06:51
- Откуда: Новороссийск
- Контактная информация:
Re: 2.1 Убить валидацию и фильтры в AR
Я говорю об Model (Форма - Form Model), которая прекрасно подходит для валидации.
AfterSave - Для этого лучше юзать события, а не переопределять метод.S c писал(а): ↑2018.01.31, 15:27 Вам об этом и говорят, что yii и AR в частности удобен на простеньких CRUD проектах. Где начинается сложная логика - начинается АД, и поэтому придумали альтернативные паттерны и подходы. Даже возможность afterSave() - превращается в ад проекта, когда проект начинает превращаться в крупного энтерпрайз монстра.
"Энтерпрайз" не означает DDD или то, что AR использовать против религии и всех моральных норм. Да и речи не было тут про "энтерпрайз".
Я и не предлагал сделать AR по всем буквам SOLID.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Режим обслуживания сайта для Yii 2.x.x
- BrusSENS
- Сообщения: 565
- Зарегистрирован: 2012.07.26, 06:51
- Откуда: Новороссийск
- Контактная информация:
Re: 2.1 Убить валидацию и фильтры в AR
Да, спасибо за уточнение, именно об этом и шла речь.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Режим обслуживания сайта для Yii 2.x.x
- BrusSENS
- Сообщения: 565
- Зарегистрирован: 2012.07.26, 06:51
- Откуда: Новороссийск
- Контактная информация:
Re: 2.1 Убить валидацию и фильтры в AR
Тут зависит от того, что Вы подразумеваете под "сложным" проектом. На некоторых проектах и PHP может не подойти по ряду причин.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Режим обслуживания сайта для Yii 2.x.x
- BrusSENS
- Сообщения: 565
- Зарегистрирован: 2012.07.26, 06:51
- Откуда: Новороссийск
- Контактная информация:
Re: 2.1 Убить валидацию и фильтры в AR
Именно для того, что бы не было таких ситуаций (что бы не гневить Всевышнего ) и предложил данный сабж.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Режим обслуживания сайта для Yii 2.x.x
-
- Сообщения: 83
- Зарегистрирован: 2017.07.04, 20:53
Re: 2.1 Убить валидацию и фильтры в AR
Да, если говорим о валидации реквеста, правила наподобие уникальности имени - это общее правило независимо от контекста web/api/консоль. Если нужно провалидировать реквест - логично использовать форму. Если нужна целостность данных то логично валидировать в ar.Обычно набор правил валидации уникален для источника данных.
Re: 2.1 Убить валидацию и фильтры в AR
впервые с вами не соглашусь) верней соглашусь, только частично.
В предложении MF-а действительно AR не обязан включать виладацию.
Но в итоге - в большинстве реализаций AR реализуют валидацию, это уже практически стандартный подход.
php, ruby, java - посмотрел - AR реализации включают валидацию в классе.
Re: 2.1 Убить валидацию и фильтры в AR
и? мысль-то поясните. Что означает по вашему традиционное наличие валидации внутри модели?S c писал(а): ↑2018.01.31, 18:37впервые с вами не соглашусь) верней соглашусь, только частично.
В предложении MF-а действительно AR не обязан включать виладацию.
Но в итоге - в большинстве реализаций AR реализуют валидацию, это уже практически стандартный подход.
php, ruby, java - посмотрел - AR реализации включают валидацию в классе.
Re: 2.1 Убить валидацию и фильтры в AR
Мысль я описывал выше. В определенных ситуациях - удобно и быстро. Создал AR класс, есть добавление с формы, есть импорт из файла, есть добавление через API. Код для всех ситуаций одинаков - получаем массив данных ($_POST, с файла, с апи, не важно, получаем массив) - $obj->save();
Если есть ошибки - опять же имеет массив ошибок и в разном виде на разные "клиенты" их отображаем. Ну это максимально быстрый и удобный подход, согласитесь? + AR валидация еще и JS код для формы генерит (если active form используем). Да, можно на мою картинку ответить: "а если сложнее логика, разные сценарии?" (что и сделали выше) . Отвечаю: AR никогда не будет хорошим паттерном для всех условий. Но для определенных - он очень удобен. Вы согласны?
Наличие валидатора внутри модели - обечпечение логики валидации (и фильтрации) в одном месте. Что даже логично (ведь AR связан с БД, и AR данные в БД запихивает, ему и проверять валидность). И не важно откуда пришли данные, поле "name" должно быть string(255), а phone - int(N).
Если есть ошибки - опять же имеет массив ошибок и в разном виде на разные "клиенты" их отображаем. Ну это максимально быстрый и удобный подход, согласитесь? + AR валидация еще и JS код для формы генерит (если active form используем). Да, можно на мою картинку ответить: "а если сложнее логика, разные сценарии?" (что и сделали выше) . Отвечаю: AR никогда не будет хорошим паттерном для всех условий. Но для определенных - он очень удобен. Вы согласны?
Наличие валидатора внутри модели - обечпечение логики валидации (и фильтрации) в одном месте. Что даже логично (ведь AR связан с БД, и AR данные в БД запихивает, ему и проверять валидность). И не важно откуда пришли данные, поле "name" должно быть string(255), а phone - int(N).
Re: 2.1 Убить валидацию и фильтры в AR
ну то есть дело в отсутствии одной строчки validate()? Я не соглашусь что это должно влиять на мое мнение.S c писал(а): ↑2018.01.31, 18:56 Мысль я описывал выше. В определенных ситуациях - удобно и быстро. Создал AR класс, есть добавление с формы, есть импорт из файла, есть добавление через API. Код для всех ситуаций одинаков - получаем массив данных ($_POST, с файла, с апи, не важно, получаем массив) - $obj->save();
Если есть ошибки - опять же имеет массив ошибок и в разном виде на разные "клиенты" их отображаем. Ну это максимально быстрый и удобный подход, согласитесь?
это заслуга чего? именно ВСТРОЕННОЙ валидации? если она будет вне, это не будет работать?
мы можем его улучшить, чтобы он подходил для бОльшего кол-ва случаев.
безусловно. но никто и не хочет его хуже сделать. Вы считаете что вынос валидатора ухудшит ваш опыт?
это бы было логично, если производилась бы валидация по правилам, связанным именно с типами данных в БД, но т.к. там проводится еще и бизнес-валидация и фильтрация, и бизнес-кейсов может быть больше чем "сохранение модели в админке", то скорее логично, чтобы модель была валидной изначально, а валидация производилась в месте применения бизнес-правил.
вот и нет. name должен быть до 255, когда идет регистрация через сайт, и равен 10 когда генерится автоматически при регистрации из мобильного приложения.
Re: 2.1 Убить валидацию и фильтры в AR
Дело не только в строчке validate(). К примеру - где будем хранить ошибки валидации? В классе "валидаторе"?ну то есть дело в отсутствии одной строчки validate()? Я не соглашусь что это должно влиять на мое мнение.
Будет больше кода. Улучшать можно до безконечности ведь. Где грани?мы можем его улучшить, чтобы он подходил для бОльшего кол-ва случаев.
А опыт причем? Автор хочет сделать +1 шаг к улучшению архитектуры. Так можно и от AR отойти в итогебезусловно. но никто и не хочет его хуже сделать. Вы считаете что вынос валидатора ухудшит ваш опыт?
Может быть, естественно. Приложение может быть и таким - что нужно вообще от AR отказываться. Если в данном случае rules() проблемны - используйте отдельно валидатор. Никаких проблем не случится. Зачем AR в yii перепиливать из-за определенных ситуаций? В большинстве случаев вполне работает и через AR validate() подходэто бы было логично, если производилась бы валидация по правилам, связанным именно с типами данных в БД, но т.к. там проводится еще и бизнес-валидация и фильтрация, и бизнес-кейсов может быть больше чем "сохранение модели в админке", то скорее логично, чтобы модель была валидной изначально, а валидация производилась в месте применения бизнес-правил.
опять же. если только в этом поле дело - не проблема. Его даже и валидировать не нужно отдельно для автоматически сгенерированного, вы точно знаете что там будет уникальная строка из 10 символов. И лично вы в том же экшене (к примеру) и сгенерируете (на этом этапе она будет уникальна и 10 символов) и присвоите эту строку.вот и нет. name должен быть до 255, когда идет регистрация через сайт, и равен 10 когда генерится автоматически при регистрации из мобильного приложения.
Мы пришли к тому - "а если у нас оказалось серьезное приложение, к которому возможно и AR не подходит", но давайте использовать таки AR. Уникальные сложные случаи валидации - никто не мешает это сделать отдельно, не убиваю возможность валидировать что то простои из коробки и одинаково для всех случаев. С этого ведь и начали
Re: 2.1 Убить валидацию и фильтры в AR
это что, имеет значение?
почему будет больше кода? я вижу это так:
это одно количество кода на самом деле. почти 100% времени уйдет на описание правил валидации.// где-то в конфиге например
$rules = [....]'
$validator = new Validator($rules);
// где то в контроллере
$errors = $this->validator->validate($model);
я имею в виду user experience, вы же про это говорите.
если большинство случаев crud, бесспорно. может стоить чуть раздивнуть рамки чтобы еще 20% сверху заиметь? не ухудшив ux программера, увеличив кол-во кейсов применения AR.S c писал(а): ↑2018.01.31, 20:29 Может быть, естественно. Приложение может быть и таким - что нужно вообще от AR отказываться. Если в данном случае rules() проблемны - используйте отдельно валидатор. Никаких проблем не случится. Зачем AR в yii перепиливать из-за определенных ситуаций? В большинстве случаев вполне работает и через AR validate() подход
откуда я знаю? у меня api для 3rd party клиентов.
нет, снаружи придет.
Да и вообще речь конечно же не о name, а об общем.
плохая позиция. есть инструмент - его можно небольшими усилиями доработать. хуже не станет. станет лучше. зачем нужен другой инструмент?S c писал(а): ↑2018.01.31, 20:29Мы пришли к тому - "а если у нас оказалось серьезное приложение, к которому возможно и AR не подходит", но давайте использовать таки AR. Уникальные сложные случаи валидации - никто не мешает это сделать отдельно, не убиваю возможность валидировать что то простои из коробки и одинаково для всех случаев. С этого ведь и начали
- BrusSENS
- Сообщения: 565
- Зарегистрирован: 2012.07.26, 06:51
- Откуда: Новороссийск
- Контактная информация:
Re: 2.1 Убить валидацию и фильтры в AR
Улучшение архитектуры приложения путём предложения по улучшению библиотеки для работы с БД? Фреймворк === архитектура?
Не поверите, так можно и от PHP отойти, если того потребует проект.
P.S.: Вам Zelenin наверное даже подтвердит, он вроде не так давно делал проект на Go.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Режим обслуживания сайта для Yii 2.x.x
Re: 2.1 Убить валидацию и фильтры в AR
Так о чем речь то? есть же валидатор от model/form, используйте его. используйте его отдельно, исспользуя AR rules()
Добавить новый сервис Validator - та без проблем. Хоть в рамках yii, хоть самому у себя в проекте.
Речь о том что бы убить\убрать\вынести validate() в AR (который полезен). Этого делать не стоит.если большинство случаев crud, бесспорно. может стоить чуть раздивнуть рамки чтобы еще 20% сверху заиметь? не ухудшив ux программера, увеличив кол-во кейсов применения AR.
Добавить новый сервис Validator - та без проблем. Хоть в рамках yii, хоть самому у себя в проекте.
как доработать? убрать удобный функционал? вынести его?плохая позиция. есть инструмент - его можно небольшими усилиями доработать. хуже не станет. станет лучше. зачем нужен другой инструмент?
Re: 2.1 Убить валидацию и фильтры в AR
Я вам не отвечаю, потому что какой-либо конкретики у вас нет вообще. набор слов пишите, извините. Я тоже писал проект на GO, и что с этого?BrusSENS писал(а): ↑2018.01.31, 21:56Улучшение архитектуры приложения путём предложения по улучшению библиотеки для работы с БД? Фреймворк === архитектура?
Не поверите, так можно и от PHP отойти, если того потребует проект.
P.S.: Вам Zelenin наверное даже подтвердит, он вроде не так давно делал проект на Go.
По теме что? валидируйте ваш объект спокойно отдельно, вам это сразу предложили. И в разных местах - используйте свои правила. Без сценариев и прочего. Рабочий ведь вариант. Убирать встроенный validate() в AR - не стоит, ибо в простейших случаях - это самый быстрый, простой и удобный функционал.
Используйте Model, FormModel (или что то подобное), напишите на коленке класс Validator. И Будет именно то, что вы хотите
Re: 2.1 Убить валидацию и фильтры в AR
сорри, оффтоп: Как вы отдельные куски мои цитируете, с ником?)
- BrusSENS
- Сообщения: 565
- Зарегистрирован: 2012.07.26, 06:51
- Откуда: Новороссийск
- Контактная информация:
Re: 2.1 Убить валидацию и фильтры в AR
Убрать его из AR в угоду строгости. Часто встречаются проекты, где от этого приходится избавляться, хотя тем, кто это писал понравилось. Просто же. Yii многое позволяет делать, с этим и есть предложение бороться. PHP и веб девелоп вырос и накладывает определенные рамки на разработчика. Пора и Yii внести строгости.S c писал(а): ↑2018.01.31, 22:40 Так о чем речь то? есть же валидатор от model/form, используйте его. используйте его отдельно, исспользуя AR rules()
Речь о том что бы убить\убрать\вынести validate() в AR (который полезен). Этого делать не стоит.
Добавить новый сервис Validator - та без проблем. Хоть в рамках yii, хоть самому у себя в проекте.
как доработать? убрать удобный функционал? вынести его?
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Режим обслуживания сайта для Yii 2.x.x