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

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

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

Сообщение BrusSENS » 2018.01.28, 00:04

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

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

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

Сообщение noLogicOnlyWar » 2018.01.28, 13:14

Какой смысл? Это не сделает AR "энтерпрайз" паттерном. AR удобен для crud => валидация и фильтрация в в ar тоже удобно. Нужны чистые сущности => не нужен ar.

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

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

Сообщение BrusSENS » 2018.01.28, 14:08

noLogicOnlyWar писал(а):
2018.01.28, 13:14
Какой смысл? Это не сделает AR "энтерпрайз" паттерном. AR удобен для crud => валидация и фильтрация в в ar тоже удобно. Нужны чистые сущности => не нужен ar.
Да успокойтесь вы уже со своим "энтерпрайзом"!!! С чего бы это мне не подойдёт AR с чистыми сущностями? Откуда вы это черпаете? Уже с ума посходили с этими академическими понятиями и подходами. Один по 200 бачей хочет толкать то, что он там напилил, якобы похожее на CMS с всякими "академичными" и "solid'ными" штуками. Второй орёт, что AR не "энтерпрайз" и его использовать не стоит.

Есть вопрос по сабжу и не надо писать не касающиеся вопроса ответы.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x

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

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

Сообщение noLogicOnlyWar » 2018.01.28, 14:21

Да успокойтесь вы уже со своим "энтерпрайзом"!!!
Беспокойный помойму не я :)
Откуда вы это черпаете?
Из опыта людей которые на этом собаку съели, вам нужны имена и источники? Они обще известны
С чего бы это мне не подойдёт AR с чистыми сущностями?
Вопрос странный, что значит "AR с чистыми сущностями"
Есть вопрос по сабжу и не надо писать не касающиеся вопроса ответы.
Ответ по теме был. Или мнения противоречащее вашему не принимаются?

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

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

Сообщение BrusSENS » 2018.01.28, 14:38

noLogicOnlyWar писал(а):
2018.01.28, 14:21
Беспокойный помойму не я :)
Именно вы, раз для вас есть единственно верный путь для разработки проектов.
noLogicOnlyWar писал(а):
2018.01.28, 14:21
Из опыта людей которые на этом собаку съели, вам нужны имена и источники? Они обще известны
Т.е. вы хотите сказать, что AR совершенно не подходит для проектов, крупнее сайта-визитки?
noLogicOnlyWar писал(а):
2018.01.28, 14:21
Вопрос странный, что значит "AR с чистыми сущностями"
Имелось ввиду использование AR для сущностей, пускай и не особо чистых.
noLogicOnlyWar писал(а):
2018.01.28, 14:21
Ответ по теме был. Или мнения противоречащее вашему не принимаются?
Вопрос был не о том, что бы сделать AR энтерпрайз паттерном. Да и AR не обязан уметь себя валидировать.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x

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

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

Сообщение noLogicOnlyWar » 2018.01.28, 15:33

Именно вы, раз для вас есть единственно верный путь для разработки проектов.
Т.е. вы хотите сказать, что AR совершенно не подходит для проектов, крупнее сайта-визитки?
Я такого не говорил.
Вопрос был не о том, что бы сделать AR энтерпрайз паттерном. Да и AR не обязан уметь себя валидировать.
Вы хотите убрать из ар валидацию, зачем? Если я правильно понял хочется нелюбимого вами solid, spr и прочего... Как по мне со своими задачами yii ar справляется хорошо и сейчас. При желание и в текущем виде можно валидацией в ар не пользоваться, валидировать входные данные в формах и делать ar->save(false).

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

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

Сообщение BrusSENS » 2018.01.28, 17:06

noLogicOnlyWar писал(а):
2018.01.28, 15:33
Вы хотите убрать из ар валидацию, зачем? Если я правильно понял хочется нелюбимого вами solid, spr и прочего... Как по мне со своими задачами yii ar справляется хорошо и сейчас. При желание и в текущем виде можно валидацией в ар не пользоваться, валидировать входные данные в формах и делать ar->save(false).
Речь не о solid. Есть идея разделить обработчик вводимых данных и AR. Зачем, по сути, два экземпляра Model-типа при обработке запроса? Вот именно, что незачем. С валидацией в AR получаются жирнейшие "модели" с кучей сценариев. А так AR будет делать ровно то, что он должен делать. Чем это плохо?
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x

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

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

Сообщение noLogicOnlyWar » 2018.01.28, 18:18

С валидацией в AR получаются жирнейшие "модели" с кучей сценариев. А так AR будет делать ровно то, что он должен делать.
Ну так вы сами знаете что можно от этого уйти используя формы, sti и подобное.
Другое дело что иногда удобно использовать ar такой какая она есть сейчас. Когда надо по быстрому, накидать прототип и уже работает.
Зачем, по сути, два экземпляра Model-типа при обработке запроса?
Затем же, зачем и 2 yii\base\Object и 2 yii\base\Component, это по моему уже более глобальный вопрос.

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

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

Сообщение BrusSENS » 2018.01.29, 01:33

noLogicOnlyWar писал(а):
2018.01.28, 18:18
Ну так вы сами знаете что можно от этого уйти используя формы, sti и подобное.
Другое дело что иногда удобно использовать ar такой какая она есть сейчас. Когда надо по быстрому, накидать прототип и уже работает.
С отдельной формой тоже не особо медленнее получается накидать, да и в удобстве не проигрывает. И не соблазняет на "я есть и тут, заюзай меня быстрее".
noLogicOnlyWar писал(а):
2018.01.28, 18:18
Затем же, зачем и 2 yii\base\Object и 2 yii\base\Component, это по моему уже более глобальный вопрос.
Ну это объекты "экосистемы" фрейма - это одно. А наследовать кучу всего, без возможности это отключить - другое. BaseObject и Component представляют базовые возможности для объекта. А вот наследование от Model накидывает уже некий функционал на объект AR.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x

Аватара пользователя
samdark
Администратор
Сообщения: 8817
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

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

Сообщение samdark » 2018.01.30, 22:52

BrusSENS,

1. Как бы мог выглядеть этот новый класс?
2. Куда собирать ошибки валидации?
3. Где и как указывать, что именно валидировать?
4. Чем не нравится Model сейчас?

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

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

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

samdark писал(а):
2018.01.30, 22:52
1. Как бы мог выглядеть этот новый класс?
2. Куда собирать ошибки валидации?
3. Где и как указывать, что именно валидировать?
4. Чем не нравится Model сейчас?
1. На эту тему можно порассуждать. В идеале существующий ныне AR без валидации и фильтров. Обработали в форме, вернули уже валидные данные.
2. Переложить валидацию непосредственно на модель формы (Model).
3. п.2
4. Model нравится. Но вот смущает что по сути имеем по сути 2 объекта одного типа. Не смертельно конечно, но разделение добавило бы строгости.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x

Аватара пользователя
samdark
Администратор
Сообщения: 8817
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

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

Сообщение samdark » 2018.01.31, 00:34

Хм... тогда не вижу причин, почему сейчас нельзя не пихать в AR валидацию и реализовать отдельные формы, если так кажется лучше.

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

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

Сообщение S c » 2018.01.31, 13:25

BrusSENS писал(а):
2018.01.28, 00:04
Собственно предложение сабже.
Есть мысли в сторону переноса ответственности за валидацию и фильтрацию в некий Form класс. Таким образом убить Model и разгрузить AR от лишней ответственности.
Что думаете насчёт этого, друзья?
зачем? для своих задач AR сверх удобен. запилил rules - и они используются абсолютно везде (данные не только от формы могут прийти, так же из rest api, из импорта с xml\xls и тд). Вынести валидацию и фильтры в form класс - что будете делать с данными, пришедшими из rest? или из xls? валидировать через некий Form класс? причем тут Form и API? именно удобство в том, чтоб все рулится в одном месте. И потом уже не паримся - из какого источника пришли данные, они нормально отвалидируются, save() не сработает, $obj->getErrors() заполнится, и ошибки можно будет удобно получить и отобразить. и получим почти одинаковые action-ы для любых действий, просто в AR аттрибуты загоняем либо $_POST либо массив из xml либо массив переданный по API.

А то что вы хотите - "перенос ответственности" - выше верно заметили, отказывайтесь от AR, реализуйте сервисы, репозитории и тд. Можете создать отдельно свой класс SomeEntityValidator, в вашу модель уже присваивать только валидные данные. Но это всё уже ближе к SOLID, DDD и тд. В любом случае, хорошо что у вас возникают идеи о разделении ответственности.

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

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

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

Либо 2й вариант (тоже дважды упомянут в теме) - использовать валидатор -
не пихать в AR валидацию и реализовать отдельные формы, если так кажется лучше
Считайте часть ответственности вынесли из AR. Но это не повод менять AR в yii.

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

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

Сообщение BrusSENS » 2018.01.31, 14:59

S c писал(а):
2018.01.31, 13:25
зачем? для своих задач AR сверх удобен. запилил rules - и они используются абсолютно везде
...
валидировать через некий Form класс? причем тут Form и API? именно удобство в том, чтоб все рулится в одном месте.
Валидация удобна, пока нет различных условий для этих правил, после чего куча сценариев и правил превращается в ад. И хорошо, если только сценарии. Видел даже, как для фронта и бэка плодят наследников AR класса. И Вы это называете удобным?
S c писал(а):
2018.01.31, 13:25
данные не только от формы могут прийти, так же из rest api, из импорта с xml\xls и тд). Вынести валидацию и фильтры в form класс - что будете делать с данными, пришедшими из rest? или из xls? валидировать через некий Form класс? причем тут Form и API?
Для этого создам отдельный сервис, который будет принимать несколько необходимых аргументов и обрабатывать:
а) Именно через форму, или AR у нас по другому валидирует?
б) Validation Bus - но это для чего-то не стандартного. Хотя и чертовски удобная. И кстати как-то использовал с AR - тоже очень удобно.
S c писал(а):
2018.01.31, 13:25
И потом уже не паримся - из какого источника пришли данные, они нормально отвалидируются, save() не сработает, $obj->getErrors() заполнится, и ошибки можно будет удобно получить и отобразить.
Прекрасно то же самое получается в работе с разделенной Form от AR.
S c писал(а):
2018.01.31, 13:25
и получим почти одинаковые action-ы для любых действий, просто в AR аттрибуты загоняем либо $_POST либо массив из xml либо массив переданный по API.
Так Command Bus же для одинаковых (не почти) действий.
S c писал(а):
2018.01.31, 13:25
А то что вы хотите - "перенос ответственности" - выше верно заметили, отказывайтесь от AR, реализуйте сервисы, репозитории и тд.
Да, я предлагаю сократить ответственность AR и увеличить ответственность разработчика. Чего в этом плохого?
Сервисы и другие вкусные штуки я и так использую в проектах, как и репо, но где это реально оправдано.
S c писал(а):
2018.01.31, 13:25
Можете создать отдельно свой класс SomeEntityValidator, в вашу модель уже присваивать только валидные данные. Но это всё уже ближе к SOLID, DDD и тд. В любом случае, хорошо что у вас возникают идеи о разделении ответственности.
SOLID != DDD. Я хочу разделять ответственность не прибегая к парадигме DDD. Не путайте понятия. SOLID - это не плохо. И сделать немного солиднее там, где это можно сделать без особых потерь - в этом ничего плохого нет.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x

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

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

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

samdark писал(а):
2018.01.31, 00:34
Хм... тогда не вижу причин, почему сейчас нельзя не пихать в AR валидацию и реализовать отдельные формы, если так кажется лучше.
Может в строну трейтов тогда посмотреть? Нужна валидация - заюзал трейт?
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x

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

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

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

S c писал(а):
2018.01.31, 13:25
именно удобство в том, чтоб все рулится в одном месте. И потом уже не паримся - из какого источника пришли данные, они нормально отвалидируются
Сомнительное удобство - рулить в одном месте. Обычно набор правил валидации уникален для источника данных. Те правила, что необходимы для пользовательской формы наверняка будут отличатся от правил для контент-менеджера и уж тем более будут разниться от api к api.

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

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

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

chesar писал(а):
2018.01.31, 15:03
S c писал(а):
2018.01.31, 13:25
именно удобство в том, чтоб все рулится в одном месте. И потом уже не паримся - из какого источника пришли данные, они нормально отвалидируются
Сомнительное удобство - рулить в одном месте. Обычно набор правил валидации уникален для источника данных. Те правила, что необходимы для пользовательской формы наверняка будут отличатся от правил для контент-менеджера и уж тем более будут разниться от api к api.
Для этого существуют сценарии

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

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

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

S c писал(а):
2018.01.31, 15:19
chesar писал(а):
2018.01.31, 15:03
S c писал(а):
2018.01.31, 13:25
именно удобство в том, чтоб все рулится в одном месте. И потом уже не паримся - из какого источника пришли данные, они нормально отвалидируются
Сомнительное удобство - рулить в одном месте. Обычно набор правил валидации уникален для источника данных. Те правила, что необходимы для пользовательской формы наверняка будут отличатся от правил для контент-менеджера и уж тем более будут разниться от api к api.
Для этого существуют сценарии
что переусложняет код. применить разные правила валидации непосредственно в месте валидации удобнее и нагляднее.

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

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

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

а) Именно через форму, или AR у нас по другому валидирует?
да, AR у нас валидирует сами данные (с дополнительной возможностью добавления клиентской валидации, путем генерации js кода на основании правил), не зависимо от формы. Причем тут форма?
Валидация удобна, пока нет различных условий для этих правил, после чего куча сценариев и правил превращается в ад. И хорошо, если только сценарии. Видел даже, как для фронта и бэка плодят наследников AR класса. И Вы это называете удобным?
Вам об этом и говорят, что yii и AR в частности удобен на простеньких CRUD проектах. Где начинается сложная логика - начинается АД, и поэтому придумали альтернативные паттерны и подходы. Даже возможность afterSave() - превращается в ад проекта, когда проект начинает превращаться в крупного энтерпрайз монстра.
SOLID != DDD. Я хочу разделять ответственность не прибегая к парадигме DDD. Не путайте понятия. SOLID - это не плохо. И сделать немного солиднее там, где это можно сделать без особых потерь - в этом ничего плохого нет.
AR - это уже не SOLID.
Последний раз редактировалось S c 2018.01.31, 15:29, всего редактировалось 1 раз.

Ответить