Form, Model, AR

Обсуждаем, как правильно строить приложения
anton_z
Сообщения: 440
Зарегистрирован: 2017.01.15, 15:01

Re: Form, Model, AR

Сообщение anton_z » 2018.03.25, 03:29

noLogicOnlyWar писал(а):
2018.03.25, 03:13

Окей, придрались ко словам законно. С моей стороны правильно было бы сказать о процедуре идентификации.
На это скажу то же самое зависиот от того, что считать "процедурой идентификации".

anton_z
Сообщения: 440
Зарегистрирован: 2017.01.15, 15:01

Re: Form, Model, AR

Сообщение anton_z » 2018.03.25, 03:41

А вот это по-вашему тоже плохо? И так тоже нельзя? Тоже SRP нарушает?

Код: Выделить всё


class LoginForm extends Model
{
    private $auth_service;
    
    public function init()
    {
        $this->auth_service = \Yii::$container->get(AuthService::class);
    }

    public function login()
    {
         $this->auth_service->login($this->login, $this->password);
    }
    
    //...


}


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

Re: Form, Model, AR

Сообщение noLogicOnlyWar » 2018.03.25, 14:36

Я не хочу холиварить и пускаться в пространные рассуждения
Люди, которые так пишут, знают распиаренный SOLID но еще пока не знают/не понимают GRASP
...
На это можете ответить, раз Вы четко понимаете определение SRP?Как все-таки правильно отделить одну обязанность от другой?
https://drive.google.com/file/d/0ByOwmq ... dDMkk/view
По мне так если определение не позволяет отделить одно от другого - такое определение не вообще ничего не стоит.
Я пользуюсь этим принципом, спрашивая себя о возможных причинах изменения класса. В конечном итоге это приносит профит. Так что я уж сам решу чего оно стоит.
Классы становятся меньше, читабельнее. Апи классов меньше, приятнее на вид и для понимания. Тесты меньше, проще, читабельнее, ошибки более локализарованы. Ситуаций когда мы используем вашу форму для рендера, а она на кой то дергает репозиторий не возникают. И тд и тп.

Ирония в том что IE как раз такое определение, допускающее разночтения.
На это скажу то же самое зависиот от того, что считать "процедурой идентификации".
Ну так к к процедуре идентификации проверка правильности ввода email "по маске" не имеет никакого отношения.
А вот это по-вашему тоже плохо? И так тоже нельзя? Тоже SRP нарушает?
Плохо? Да. Нарушает SRP? Нет. Ответственность делегирована другому классу. Форма является фасадом. По мне это плохо потому что loginForm не то место где ожидаешь увидеть метод login.
Последний раз редактировалось noLogicOnlyWar 2018.03.25, 14:46, всего редактировалось 1 раз.

Auramel
Сообщения: 80
Зарегистрирован: 2017.11.17, 14:39
Откуда: Russia, Ufa
Контактная информация:

Re: Form, Model, AR

Сообщение Auramel » 2018.03.25, 14:42

Ох, какая тут дискуссия пошла. Приятно видеть рабочий процесс :)
Я, Вас, ребят, не сильно понимаю xD
Насчет последнего сообщения - я б сделал конструктор и в него передавал authservice. В остальном - все же, я считаю, что метод login не должен быть в форме...
А если методов авторизации несколько? Типа для сайта yii/web/user:login, а для консоли второй, для реста третий, а ещё сокеты подключим и захотим, чтобы там авторизация была, а форму мы хотим единую. Тогда, придется писать в LoginForm типа siteLogin() consoleLogin и т.д. и где-то будет yii::app->user->login, а где-то типа app/console/user::login.
Наверное, полную хрень написал. Поправьте, если че.

Использование Yii::foo - это сахар. Потом это становится привычкой. Открываешь другой проект и понимаешь, что там по-другому и пытаешься сделать также.

С телефона пишу, сорян.

anton_z
Сообщения: 440
Зарегистрирован: 2017.01.15, 15:01

Re: Form, Model, AR

Сообщение anton_z » 2018.03.25, 15:14

noLogicOnlyWar писал(а):
2018.03.25, 14:36
Я пользуюсь этим принципом, спрашивая себя о возможных причинах изменения класса. В конечном итоге это приносит профит. Так что я уж сам решу чего оно стоит.
Классы становятся меньше, читабельнее. Апи классов меньше, приятнее на вид и для понимания. Тесты меньше, проще, читабельнее, ошибки более локализарованы. Ситуаций когда мы используем вашу форму для рендера, а она на кой то дергает репозиторий не возникают. И тд и тп.
Ладно, приносит профит, а это главное. Мне GRASP приносит профит, SRP я отношу к "эвристике". Каждому свое.
Не хочу больше спорить. Вы не хотите годность GRASP признавать, я SRP. Надо на этом и остановиться.
Последний раз редактировалось anton_z 2018.03.25, 15:19, всего редактировалось 1 раз.

anton_z
Сообщения: 440
Зарегистрирован: 2017.01.15, 15:01

Re: Form, Model, AR

Сообщение anton_z » 2018.03.25, 15:18

Auramel писал(а):
2018.03.25, 14:42

А если методов авторизации несколько? Типа для сайта yii/web/user:login, а для консоли второй, для реста третий, а ещё сокеты подключим и захотим, чтобы там авторизация была, а форму мы хотим единую. Тогда, придется писать в LoginForm типа siteLogin() consoleLogin и т.д. и где-то будет yii::app->user->login, а где-то типа app/console/user::login.
Необязательно один класс формы. Можно и несколько - по одному на каждый случай. Общее поведение можно всегда вынести в базовый класс или стратегию.

Auramel
Сообщения: 80
Зарегистрирован: 2017.11.17, 14:39
Откуда: Russia, Ufa
Контактная информация:

Re: Form, Model, AR

Сообщение Auramel » 2018.03.25, 15:36

anton_z писал(а):
2018.03.25, 15:18
Auramel писал(а):
2018.03.25, 14:42

А если методов авторизации несколько? Типа для сайта yii/web/user:login, а для консоли второй, для реста третий, а ещё сокеты подключим и захотим, чтобы там авторизация была, а форму мы хотим единую. Тогда, придется писать в LoginForm типа siteLogin() consoleLogin и т.д. и где-то будет yii::app->user->login, а где-то типа app/console/user::login.
Необязательно один класс формы. Можно и несколько - по одному на каждый случай. Общее поведение можно всегда вынести в базовый класс или стратегию.
И то верно

Аватара пользователя
maleks
Сообщения: 1796
Зарегистрирован: 2012.12.26, 12:56

Re: Form, Model, AR

Сообщение maleks » 2018.03.25, 19:38

Auramel писал(а):
2018.03.25, 14:42
В остальном - все же, я считаю, что метод login не должен быть в форме...
Тем не менее в проектах на yii вы там его будете часто встречать. Это часть того mvc что идет из коробки.

Например вы в слиме, если быстро глянуть доку, стартуете без какой то выраженной модели из коробки, пишете контроллер, знаете что он должен быть тонкий, и быстро упорхаете из него писать "бизнес логику" или все что захочется в какой то сервис, а какой он там получится, кто знает.
А в yii из контроллера предлагают работать с Моделью, и она уже есть в этом контроллере - форма или AR объект. Ключевое тут что это модели. Поэтому там код и оказывается. А что не влезает, остается в контроллере. :)
Понятно что с точки зрения теории и слоистых систем тут не все окей, особенно когда момент с моделями-формами.

Auramel
Сообщения: 80
Зарегистрирован: 2017.11.17, 14:39
Откуда: Russia, Ufa
Контактная информация:

Re: Form, Model, AR

Сообщение Auramel » 2018.03.25, 20:28

maleks писал(а):
2018.03.25, 19:38
Auramel писал(а):
2018.03.25, 14:42
В остальном - все же, я считаю, что метод login не должен быть в форме...
Тем не менее в проектах на yii вы там его будете часто встречать. Это часть того mvc что идет из коробки.

Например вы в слиме, если быстро глянуть доку, стартуете без какой то выраженной модели из коробки, пишете контроллер, знаете что он должен быть тонкий, и быстро упорхаете из него писать "бизнес логику" или все что захочется в какой то сервис, а какой он там получится, кто знает.
А в yii из контроллера предлагают работать с Моделью, и она уже есть в этом контроллере - форма или AR объект. Ключевое тут что это модели. Поэтому там код и оказывается. А что не влезает, остается в контроллере. :)
Понятно что с точки зрения теории и слоистых систем тут не все окей, особенно когда момент с моделями-формами.
Это да, встречается в 10 из 10 проектах. С одной стороны грустно, а с другой - я всегда знаю, что этот метод там есть. У каждого из нас свой взгляд и это факт.

Тем слим и нравится, что он "пустой", а если нужны аддоны - их несложно прикрутить и засунуть в container. Мб yii 3-ей версии сделать такой же "пустой", а с помощью композера или ещё чего дотягивать нужные вещи. Было бы очень круто.

anton_z
Сообщения: 440
Зарегистрирован: 2017.01.15, 15:01

Re: Form, Model, AR

Сообщение anton_z » 2018.03.26, 03:11

Хорошая статья про SRP, которя объясняет, что с ним не так

http://sklivvz.com/posts/i-dont-love-th ... -principle

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

Re: Form, Model, AR

Сообщение noLogicOnlyWar » 2018.03.26, 10:57

Каждому свое.
Не хочу больше спорить. Вы не хотите годность GRASP признавать, я SRP. Надо на этом и остановиться.
Странный вывод про grasp. Я признаю, но не вижу причины ставить IE принцип впереди остальных. Он не дает классам вырождаться в функции, чтото без внутреннего состояния. Использование сервисов само по себе не делает модель анемичной. Сервисы не противоречат ооп. Суть - использовать их аккуратно и к месту, а не везде подряд.

Auramel
Сообщения: 80
Зарегистрирован: 2017.11.17, 14:39
Откуда: Russia, Ufa
Контактная информация:

Re: Form, Model, AR

Сообщение Auramel » 2018.03.26, 21:32

Если вдруг кому-то интересно про viewmodel - нашел небольшой пример. Мб и не совсем правильный. Хотя бы общую картину вырисовывает. https://www.sourcetoad.com/code/view-mo ... framework/

UPD: Небольшой вопрос вдогонку (насчет AR и view) - встретил проект, где есть GridView и ListView. Кто помнит - в GridView в columns можно сделать

Код: Выделить всё

[
	'attribute' => 'foo', 
	'value' => function ($model) {
		# code
	} 
]
благодаря такой конструкции можно намутить дичь аля $model::find(). И да, такое рили встречается (вы же итак уже это знаете, не?) Такие вещи как-нибудь можно пресечь, кроме как отказаться от подобных виджетов?

UPD2:
anton_z писал(а):
2018.03.26, 03:11
Хорошая статья про SRP, которя объясняет, что с ним не так

http://sklivvz.com/posts/i-dont-love-th ... -principle
My english very well ) Есть стимул подучить английский и почитать подобные статьи.

Аватара пользователя
SiZE
Сообщения: 2698
Зарегистрирован: 2011.09.21, 12:39
Откуда: Perm
Контактная информация:

Re: Form, Model, AR

Сообщение SiZE » 2018.03.27, 09:28

anton_z писал(а):
2018.03.26, 03:11
Хорошая статья про SRP, которя объясняет, что с ним не так

http://sklivvz.com/posts/i-dont-love-th ... -principle
То то на каждом шагу у нас слезы о том что в AR слишком много напихано.
в поиске работы

Аватара пользователя
maleks
Сообщения: 1796
Зарегистрирован: 2012.12.26, 12:56

Re: Form, Model, AR

Сообщение maleks » 2018.03.27, 09:37

anton_z писал(а):
2018.03.26, 03:11
Хорошая статья про SRP, которя объясняет, что с ним не так
Он там дальше и OCP недоволен.
Вообще забавно что в других науках - физики, химии, биологии, математике, и по БД и т.д., профессора и к.т.н-ы все подробно разжевали, а вот по ООП они чего то вроде и не спешат. Непонятно как они учат студентов, например в нормальных вузах, неужели этой статьей от дяди Боба, которая из имеющегося до сих пор выглядит как лучшая...

Аватара пользователя
maleks
Сообщения: 1796
Зарегистрирован: 2012.12.26, 12:56

Re: Form, Model, AR

Сообщение maleks » 2018.03.27, 09:55

SiZE писал(а):
2018.03.27, 09:28
То то на каждом шагу у нас слезы о том что в AR слишком много напихано.
Смотря о какой AR говорить.
Та Фаулеровская AR в которой Доменные объекты разделяют еще способность доступа к БД. Две ответственности. И я у Фаулера нигде не встречал чтобы он назвал эту orm негодной.
Или та AR с кучей финтифлюшек для пользователей которую представил RoR, а за ним и php фреймы. Где под бизнес логикой обычно понимаются правила валидации форм и т.д..

Best prictices о использовании вот этой первой AR тоже как то не особо нагугливаются.

anton_z
Сообщения: 440
Зарегистрирован: 2017.01.15, 15:01

Re: Form, Model, AR

Сообщение anton_z » 2018.03.29, 01:45

noLogicOnlyWar писал(а):
2018.03.26, 10:57
Странный вывод про grasp. Я признаю, но не вижу причины ставить IE принцип впереди остальных. Он не дает классам вырождаться в функции, чтото без внутреннего состояния. Использование сервисов само по себе не делает модель анемичной.
А как вам такая причина - GRASP и SRP призваны решать одну задачу - распределение обязанностей, поэтому, зачем ипользовать их оба? Для себя выбрал именно GRASP, так как он гораздо более полон и имеет в себе несколько принципов в отличие от нечекого дял меня SRP.
Сервисы не противоречат ооп. Суть - использовать их аккуратно и к месту, а не везде подряд.
Так можно вообще про любую вещь в мире сказать - "использовать аккуратно и к месту", это простая истина. А вот как отличить такие места от любых других - уже не такой тривиальный вопрос.

Использование сервисов, да, само по себе не противоречит ООП, если туда не выносить из моделей всю реальную работу, делая их анемичными: бизнес-логику, генерацию событий и прочее, как в соседней теме https://yiiframework.ru/forum/viewtopic ... 34&t=46781. Конечно, если подходящей модели не нашлось, или модель станет слишком сильно связанной, можно использовать сервис (в GRASP, кстати, есть и для этого принцип - Pure Fabrication).

Еще поделюсь соображениями. Иногда встречал такое правило: "если бизнес-логика использует несколько моделей - ее место в сервисе". С этим я тоже не совсем согласен. Я думаю, что сначала стоит попробовать из этих нескольких моделей одну выбрать (сделать агрегатом) и туда эту бизнес-логику поместить - ничего страшного, если модель внутри себя будет использовать другие модели.
Ситуаций когда мы используем вашу форму для рендера, а она на кой то дергает репозиторий не возникают. И тд и тп.
Это прямо такой гигантский минус который сразу делает форму плохой. Если так не нравится обращение к контейнеру в init() его можно перенести прямо в login().
Последний раз редактировалось anton_z 2018.03.29, 04:26, всего редактировалось 9 раз.

anton_z
Сообщения: 440
Зарегистрирован: 2017.01.15, 15:01

Re: Form, Model, AR

Сообщение anton_z » 2018.03.29, 01:49

SiZE писал(а):
2018.03.27, 09:28
То то на каждом шагу у нас слезы о том что в AR слишком много напихано.
Это из-за проделок новичков и тех, кто не желает узнавать что-то новое, осваивать лучшие практики, а не из-за тех, кто находит неточности/непонятки в декларируемых принципах.

Ответить