2.1 Убить валидацию и фильтры в AR
- BrusSENS
- Сообщения: 565
- Зарегистрирован: 2012.07.26, 06:51
- Откуда: Новороссийск
- Контактная информация:
2.1 Убить валидацию и фильтры в AR
Собственно предложение сабже.
Есть мысли в сторону переноса ответственности за валидацию и фильтрацию в некий Form класс. Таким образом убить Model и разгрузить AR от лишней ответственности.
Что думаете насчёт этого, друзья?
Есть мысли в сторону переноса ответственности за валидацию и фильтрацию в некий Form класс. Таким образом убить Model и разгрузить AR от лишней ответственности.
Что думаете насчёт этого, друзья?
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Режим обслуживания сайта для Yii 2.x.x
-
- Сообщения: 83
- Зарегистрирован: 2017.07.04, 20:53
Re: 2.1 Убить валидацию и фильтры в AR
Какой смысл? Это не сделает AR "энтерпрайз" паттерном. AR удобен для crud => валидация и фильтрация в в ar тоже удобно. Нужны чистые сущности => не нужен ar.
- BrusSENS
- Сообщения: 565
- Зарегистрирован: 2012.07.26, 06:51
- Откуда: Новороссийск
- Контактная информация:
Re: 2.1 Убить валидацию и фильтры в AR
Да успокойтесь вы уже со своим "энтерпрайзом"!!! С чего бы это мне не подойдёт AR с чистыми сущностями? Откуда вы это черпаете? Уже с ума посходили с этими академическими понятиями и подходами. Один по 200 бачей хочет толкать то, что он там напилил, якобы похожее на CMS с всякими "академичными" и "solid'ными" штуками. Второй орёт, что AR не "энтерпрайз" и его использовать не стоит.noLogicOnlyWar писал(а): ↑2018.01.28, 13:14 Какой смысл? Это не сделает AR "энтерпрайз" паттерном. AR удобен для crud => валидация и фильтрация в в ar тоже удобно. Нужны чистые сущности => не нужен ar.
Есть вопрос по сабжу и не надо писать не касающиеся вопроса ответы.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Режим обслуживания сайта для Yii 2.x.x
-
- Сообщения: 83
- Зарегистрирован: 2017.07.04, 20:53
Re: 2.1 Убить валидацию и фильтры в AR
Беспокойный помойму не яДа успокойтесь вы уже со своим "энтерпрайзом"!!!
Из опыта людей которые на этом собаку съели, вам нужны имена и источники? Они обще известныОткуда вы это черпаете?
Вопрос странный, что значит "AR с чистыми сущностями"С чего бы это мне не подойдёт AR с чистыми сущностями?
Ответ по теме был. Или мнения противоречащее вашему не принимаются?Есть вопрос по сабжу и не надо писать не касающиеся вопроса ответы.
- BrusSENS
- Сообщения: 565
- Зарегистрирован: 2012.07.26, 06:51
- Откуда: Новороссийск
- Контактная информация:
Re: 2.1 Убить валидацию и фильтры в AR
Именно вы, раз для вас есть единственно верный путь для разработки проектов.
Т.е. вы хотите сказать, что AR совершенно не подходит для проектов, крупнее сайта-визитки?noLogicOnlyWar писал(а): ↑2018.01.28, 14:21 Из опыта людей которые на этом собаку съели, вам нужны имена и источники? Они обще известны
Имелось ввиду использование AR для сущностей, пускай и не особо чистых.
Вопрос был не о том, что бы сделать AR энтерпрайз паттерном. Да и AR не обязан уметь себя валидировать.noLogicOnlyWar писал(а): ↑2018.01.28, 14:21 Ответ по теме был. Или мнения противоречащее вашему не принимаются?
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Режим обслуживания сайта для Yii 2.x.x
-
- Сообщения: 83
- Зарегистрирован: 2017.07.04, 20:53
Re: 2.1 Убить валидацию и фильтры в AR
Именно вы, раз для вас есть единственно верный путь для разработки проектов.
Я такого не говорил.Т.е. вы хотите сказать, что AR совершенно не подходит для проектов, крупнее сайта-визитки?
Вы хотите убрать из ар валидацию, зачем? Если я правильно понял хочется нелюбимого вами solid, spr и прочего... Как по мне со своими задачами yii ar справляется хорошо и сейчас. При желание и в текущем виде можно валидацией в ар не пользоваться, валидировать входные данные в формах и делать ar->save(false).Вопрос был не о том, что бы сделать AR энтерпрайз паттерном. Да и AR не обязан уметь себя валидировать.
- BrusSENS
- Сообщения: 565
- Зарегистрирован: 2012.07.26, 06:51
- Откуда: Новороссийск
- Контактная информация:
Re: 2.1 Убить валидацию и фильтры в AR
Речь не о solid. Есть идея разделить обработчик вводимых данных и AR. Зачем, по сути, два экземпляра Model-типа при обработке запроса? Вот именно, что незачем. С валидацией в AR получаются жирнейшие "модели" с кучей сценариев. А так AR будет делать ровно то, что он должен делать. Чем это плохо?noLogicOnlyWar писал(а): ↑2018.01.28, 15:33 Вы хотите убрать из ар валидацию, зачем? Если я правильно понял хочется нелюбимого вами solid, spr и прочего... Как по мне со своими задачами yii ar справляется хорошо и сейчас. При желание и в текущем виде можно валидацией в ар не пользоваться, валидировать входные данные в формах и делать ar->save(false).
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Режим обслуживания сайта для Yii 2.x.x
-
- Сообщения: 83
- Зарегистрирован: 2017.07.04, 20:53
Re: 2.1 Убить валидацию и фильтры в AR
Ну так вы сами знаете что можно от этого уйти используя формы, sti и подобное.С валидацией в AR получаются жирнейшие "модели" с кучей сценариев. А так AR будет делать ровно то, что он должен делать.
Другое дело что иногда удобно использовать ar такой какая она есть сейчас. Когда надо по быстрому, накидать прототип и уже работает.
Затем же, зачем и 2 yii\base\Object и 2 yii\base\Component, это по моему уже более глобальный вопрос.Зачем, по сути, два экземпляра Model-типа при обработке запроса?
- BrusSENS
- Сообщения: 565
- Зарегистрирован: 2012.07.26, 06:51
- Откуда: Новороссийск
- Контактная информация:
Re: 2.1 Убить валидацию и фильтры в AR
С отдельной формой тоже не особо медленнее получается накидать, да и в удобстве не проигрывает. И не соблазняет на "я есть и тут, заюзай меня быстрее".noLogicOnlyWar писал(а): ↑2018.01.28, 18:18 Ну так вы сами знаете что можно от этого уйти используя формы, sti и подобное.
Другое дело что иногда удобно использовать ar такой какая она есть сейчас. Когда надо по быстрому, накидать прототип и уже работает.
Ну это объекты "экосистемы" фрейма - это одно. А наследовать кучу всего, без возможности это отключить - другое. BaseObject и Component представляют базовые возможности для объекта. А вот наследование от Model накидывает уже некий функционал на объект AR.noLogicOnlyWar писал(а): ↑2018.01.28, 18:18 Затем же, зачем и 2 yii\base\Object и 2 yii\base\Component, это по моему уже более глобальный вопрос.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Режим обслуживания сайта для Yii 2.x.x
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: 2.1 Убить валидацию и фильтры в AR
BrusSENS,
1. Как бы мог выглядеть этот новый класс?
2. Куда собирать ошибки валидации?
3. Где и как указывать, что именно валидировать?
4. Чем не нравится Model сейчас?
1. Как бы мог выглядеть этот новый класс?
2. Куда собирать ошибки валидации?
3. Где и как указывать, что именно валидировать?
4. Чем не нравится Model сейчас?
Нравится Yii? Давайте сделаем его лучше!.
- BrusSENS
- Сообщения: 565
- Зарегистрирован: 2012.07.26, 06:51
- Откуда: Новороссийск
- Контактная информация:
Re: 2.1 Убить валидацию и фильтры в AR
1. На эту тему можно порассуждать. В идеале существующий ныне AR без валидации и фильтров. Обработали в форме, вернули уже валидные данные.
2. Переложить валидацию непосредственно на модель формы (Model).
3. п.2
4. Model нравится. Но вот смущает что по сути имеем по сути 2 объекта одного типа. Не смертельно конечно, но разделение добавило бы строгости.
Native Web - небольшой блог о веб разработке (временно на ремонте)
Режим обслуживания сайта для Yii 2.x.x
Режим обслуживания сайта для Yii 2.x.x
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: 2.1 Убить валидацию и фильтры в AR
Хм... тогда не вижу причин, почему сейчас нельзя не пихать в AR валидацию и реализовать отдельные формы, если так кажется лучше.
Нравится Yii? Давайте сделаем его лучше!.
Re: 2.1 Убить валидацию и фильтры в 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 и тд. В любом случае, хорошо что у вас возникают идеи о разделении ответственности.
Re: 2.1 Убить валидацию и фильтры в AR
Либо 2й вариант (тоже дважды упомянут в теме) - использовать валидатор -
Считайте часть ответственности вынесли из AR. Но это не повод менять AR в yii.не пихать в AR валидацию и реализовать отдельные формы, если так кажется лучше
- BrusSENS
- Сообщения: 565
- Зарегистрирован: 2012.07.26, 06:51
- Откуда: Новороссийск
- Контактная информация:
Re: 2.1 Убить валидацию и фильтры в AR
Валидация удобна, пока нет различных условий для этих правил, после чего куча сценариев и правил превращается в ад. И хорошо, если только сценарии. Видел даже, как для фронта и бэка плодят наследников AR класса. И Вы это называете удобным?
Для этого создам отдельный сервис, который будет принимать несколько необходимых аргументов и обрабатывать:
а) Именно через форму, или AR у нас по другому валидирует?
б) Validation Bus - но это для чего-то не стандартного. Хотя и чертовски удобная. И кстати как-то использовал с AR - тоже очень удобно.
Прекрасно то же самое получается в работе с разделенной Form от AR.
Так Command Bus же для одинаковых (не почти) действий.
Да, я предлагаю сократить ответственность AR и увеличить ответственность разработчика. Чего в этом плохого?
Сервисы и другие вкусные штуки я и так использую в проектах, как и репо, но где это реально оправдано.
SOLID != DDD. Я хочу разделять ответственность не прибегая к парадигме DDD. Не путайте понятия. 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
Re: 2.1 Убить валидацию и фильтры в AR
Сомнительное удобство - рулить в одном месте. Обычно набор правил валидации уникален для источника данных. Те правила, что необходимы для пользовательской формы наверняка будут отличатся от правил для контент-менеджера и уж тем более будут разниться от api к api.
Re: 2.1 Убить валидацию и фильтры в AR
Для этого существуют сценарии
Re: 2.1 Убить валидацию и фильтры в AR
что переусложняет код. применить разные правила валидации непосредственно в месте валидации удобнее и нагляднее.S c писал(а): ↑2018.01.31, 15:19Для этого существуют сценарии
Re: 2.1 Убить валидацию и фильтры в AR
да, AR у нас валидирует сами данные (с дополнительной возможностью добавления клиентской валидации, путем генерации js кода на основании правил), не зависимо от формы. Причем тут форма?а) Именно через форму, или AR у нас по другому валидирует?
Вам об этом и говорят, что yii и AR в частности удобен на простеньких CRUD проектах. Где начинается сложная логика - начинается АД, и поэтому придумали альтернативные паттерны и подходы. Даже возможность afterSave() - превращается в ад проекта, когда проект начинает превращаться в крупного энтерпрайз монстра.Валидация удобна, пока нет различных условий для этих правил, после чего куча сценариев и правил превращается в ад. И хорошо, если только сценарии. Видел даже, как для фронта и бэка плодят наследников AR класса. И Вы это называете удобным?
AR - это уже не SOLID.SOLID != DDD. Я хочу разделять ответственность не прибегая к парадигме DDD. Не путайте понятия. SOLID - это не плохо. И сделать немного солиднее там, где это можно сделать без особых потерь - в этом ничего плохого нет.
Последний раз редактировалось S c 2018.01.31, 15:29, всего редактировалось 1 раз.