Это видео недоступно.
Сожалеем об этом.
Laravel Model Attributes Cast | Преобразование типов атрибутов в моделях Laravel
HTML-код
- Опубликовано: 2 авг 2021
- В этом уроке рассмотрим пример того, как можно хранить объект атрибутах моделей при помощи встроенного механизма преобразования типов (cast) Laravel.
✅ Instagram: / lectoria.pro
✅ VK: lectoria
✅ Facebook: lectori...
✅ Сайт проекта Lectoria: lectoria.pro
🖥 Обучение веб-разработке Lectoria: / @lectoria
🖥 Обучение разработке на MODX Revolution: / openmodx
Спасибо!!! Вы большой молодец. Как обычно все по делу и без воды.
Столько всего…. Ух!!! Когда в начале пути и видишь такое написание невольно начинаешь сомневаться в себе, на верном ли ты пути - юнец )))
Спасибо большое!
Ух! Когда видишь подобное написание, а ты сам в начале пути - невольно начинаешь сомневаться в себе, на верном ли пути юнец?))))
Ровно тоже самое можно сделать, если в модели в свойстве каст прописать 'json' напротив нужного поля, а само поле в таблице должно быть строкой. И без никаких дополнительных классов - кастов.
А зачем каждому полю прописывать модификатор nullable(false), если они по умолчанию создаются с модификатором not null?
Подскажите, а у вас есть курс по ларавел? Очень нравится, как вы разбираете различные кейсы. Полезно для тех, кто уже знаком с фреймворком, но хочет углубиться в его познании)
Пока по Laravel ничего масштабного не записывал, но есть в планах составить учебную программу, нужно только придумать что-то интересное.
Как всегда, видео супер!
Не могли бы вы сделать видео или в инстаграмме кратко рассказать когда следует использовать геттеры и сеттеры в ларавел? И может быть немного об использовании DTO и нужны ли они вовсе?
Про геттеры и сеттеры могу сказать, что геттеры удобно использовать, например, для комбинированных атрибутов. К примеру, у меня есть таблица users, в которой есть три поля: firstname, middlename, lastname. И геттер getFullNameAttribute, который выдает нам полное имя (ФИО). И в этом случае он будет как нельзя кстати упрощать обращение к фиктивному атрибуту, которого нет в базе данных: $model->fullName
Сеттеры удобны в том случае, когда, например, у вас есть четкое соглашение внутри проекта о стиле хранения каких-то данных в таблицах. Например, вы договорились, что у вас имя, фамилия, отчество, обязательно должны храниться с большой буквы, в этом случае, сеттер (он же мутатор) setFirstnameAttribute($value){ return ucfirst($value); } будет очень кстати и вам не нужно будет нагораживать какие-то доп. конструкции в тех местах, где вы делаете: $model->firstname = 'аркадий'; - такой атрибует все равно будет сохранен со значением "Аркадий"
Что же касается DTO, то я не часто такой шаблон использую, но все же в последнее время, особенно на текущем проекте, понимаю, насколько он может обезопасить от некорректных данных и в то же время он упрощает работу с кодом. Но опять же, как показывает практика, на небольших проектах, можно обойтись и без DTO и при этом без ущерба моей производительности.
@@lectoria Огромное спасибо!
@@lectoria вы путаете понятия свойств и атрибутов. Более того если речь идет о полном имени то уже можно говорить о внедрении ValueObject который будет представлять имя и фамилию пользователя.
Видео супер!
как раз искал выход из своей ситуации сделать более гибкую систему но в то же время отслеживать ключи!
Как всегда вы лучший!!!
UPD: могу ли я хранить в json полиморфную связь?
Насчет полиморфной связи в json - я так на практике никогда не делал, но уверен на все 100%, что в Laravel такое возможно, ибо уровень кастомизации там предусмотрен очень глубокий. Другой вопрос, нужно ли оно вам? Подумайте, может быть просто имеет смысл сделать дополнительный столбец в таблице и хранить там имя полиморфного класса модели, как рекомендуется в оф. документации?
@@lectoria принял) скорее всего сделаю отдельную таблицу для хранения таких данных
Почему нельзя сделать проверку формата в мутаторе?
Можно. Я вроде не говорил, что этого нельзя делать. Это всего лишь вопрос группировки логики. Даже несмотря на то, что документация дает информацию по отдельным вопросам, все равно остается свобода структурирования классов, группировки их в отдельные блоки и так далее. Поэтому, если вам в вашем проекте удобнее проверять формат в мутаторе, то почему бы и нет ))
php artisan make:model BalanceTransaction -m создаст сразу и модель и миграцию а так php artisan make:model BalanceTransaction -mfc модель миграцию контроллер и фабрику
А когда возникает в логе "Ошибка: rejectCode = 763", то и вперёд... Ctrl + Shift + F... grep... потом ещё думай почему именно 763...
Используйте строковые коды! rejectCode = 'rejected'. Прям константой в классе, не стесняйтесь. Это работает как числа, только вы прям словами пишете что имеете в виду, и даже комментарий оставлять не понадобится. Очень сэкономит время поддержки кода.
Нет ни одной причины использовать числовые коды в нашем веке (кроме бинарных флагов). А получившаяся модель - полный трэш со всеми антипаттернами. Вы чему учите? Вы хоть одну книгу по программированию читали или только языком на лохах зарабатывать любите?
Пожалуй, единственная причина, по которой я использую числовые коды - это для совместимости с классами Exception в PHP, где при помоищ $e->getCode() можно получить только числовой код ошибки. А так я с вами согласен - строковые коды куда информативнее, чем числовые. Но в то же время, конкретно в этом случае я не вижу преимуществ у строковых кодов, кроме как наглядность при просмотре таблицы БД.
А что касается антипаттернов, кроме денормализации БД, что еще отметите?
@@lectoria Я во второй раз не стану пересматривать видео только чтобы ответить про остальные антипаттерны. Рекомендую просто вообще забыть про метод getCode у эксепшенов и опираться только на сам класс эксепшена.
Спасибо все отлично! Зачем писали toArray ?
Да уж и не помню ) Может по привычке из modx ))
@@lectoria Спасибо за оперативность. Как полученные данные из БД (в виде JSON) установить в качестве атрибутов модели? У меня отдает JSON строку, по видео все сделал (РАБОТАЕТ ОТЛИЧНО и понятно!) Если ->first BalanceTransaction отдает JSON в #attributes:, если dd(BalanceTransaction[status_context] отдает объект BalanceTransactionStructere.... и т.д. ( у меня другие сущности, но вопрос не в этом). Как атрибуты BalanceTransactionStructere.... назначить BalanceTransaction (у меня они прописаны в модели основной = здесь BalanceTransaction) ? Мне нужно просто потом работать с одной основной моделью, а перебирать объекты разные геморройно ....
Вопрос снят назначил в конструкторе $свойство ?? null; ))
Лучше скрывать окно БД в редакторе,
0:21
Вот сразу непонятно, почему будет где-то один формат данных, а где-то другой? Если как вы сказали, будет json формат. Хотелось бы сначала увидеть пример этого.
И в следствии этого далее, когда смотрел видео уже не понимал, что вы делаете и для чего это все таки нужно.
Здесь имеется ввиду, что в одних строках в этом поле будет, например {"data1":"blabla", "data2":"example"}, а в других будет что-то типа {"another_key":"another_data"}
И вот, чтобы такой ситуации избежать, можно прибегнуть к трансляции значения в поле к объекту, где у нас четко описаны поля (в случае урока это reject_code и message, а в случае, который я описал выше, это будут поля data1 и data2.
@@lectoria Уже стало понятнее спасибо, вот, если бы это было сразу в видео.
Только вот еще интересно, почему будет плохо из-за {"data1":"blabla", "data2":"example"} и {"another_key":"another_data"}
ведь в коде будет проверка на конкретную переменную в массиве или объекте, когда будем вытаскивать из полей.
И еще интересно почему там в одном месте будет data1, а в другом месте another_key. Ведь мы то будем писать одни и те же объекты. Вот если бы такой пример еще был, который воссоздавал ситуацию, где и каким образом у нас пишется в одно поле одни данные, а в другое другие, было бы просто замечательно и всё тогда понятно.
@@alexandr-v Ну вот смотрите, предположим у вас есть проект, который вы активно дорабатываете на протяжении полугода. И где-то в одном классе, вы записываете в поле модели просто json-строку {"reject_message":"blabla"}, а потом вы про это благополучно забыли, и где-то в новом классе вы уже пишете строку {"rejectMessage":"example"} и по итогу получаем, что смысл данных один и тот же, но ключи разные. Вот, чтобы такого избежать, лучше прямо на старте продумать класс объекта данных в этом поле и сделать трансляцию типов и решить, что в это поле вы всегда будете передавать объект, а не json-строку. И тогда вероятность описанной выше ситуации будет сведена практически к нулю.
@@lectoria Хорошо, подумаю над этим.
@@lectoria ну по идее в том и прелесть JSON-а, что можно сохранять в одном поле разные структуры данных.
А так же без проблем расширять эти структуры.
То, что мы создаем обвязки вокруг этого поля, ограничивает нас в создании доп. полей в этом JSON.
Что наглухо убивает саму идею его применения.
С таким же успехом рядом можно создать табличку 1:1 balance_transaction_status_context (id_bt, reject_code, message).
И работать это будет без JSON даже в mysql5
Но в целом, идея CAST-ов понятна
что за шум???? .... микрофон дкшевый наверное, не дает сосредоточиться
Это я его слишком близко к маку поставил, на записи мак начинает активно охлаждать и все это попало в звук. К сожалению, на пост-продакшне, его вырезать никак не получилось. В следующем видео постараюсь как-то развести микрофон и мак.