UB
Size: a a a
2020 February 07
AH
отличный вариант
Нет. Вариант хороший, но не отличный.
И
я же так и сказал, все зависит от уровня абстракций, но это не везде нужно
UB
Давайте не холиварить. Самый распространённый и удобный варик - держать в константах в модели
AH
я же так и сказал, все зависит от уровня абстракций, но это не везде нужно
Даже мелкий проект нужно писать хорошо.
А сейчас ощущение что чем мельче проект, тем больше советов класса "и так сойдет".
А сейчас ощущение что чем мельче проект, тем больше советов класса "и так сойдет".
UB
Возможно можно поизвращаться и придумать чтонить пооптимальнее
UB
Но зачем?
AH
Давайте не холиварить. Самый распространённый и удобный варик - держать в константах в модели
Распространенный не значит хороший ;)
UB
Распространенный не значит хороший ;)
Назови минусы такого варианта?
DM
Назови минусы такого варианта?
Я влезу тут, выше описал минус, точнее даже не минус, а нюанс.
Так вот при таком подходе раз в какое-то время шедулер должен запускать скрипт, который будет проходить по базе и менять статус, чего хотелось-бы избежать (база может стать большой). А в случае если это виртуальное поле, то оно считается динамически основываясь на других полях. Т.е. явно статуса нет, но по савокупности данных в разных полях ацессор вернёт статус. Но блин, как-то тоже сомнительно.
IG
в чем прикол, дал имя ресурсу, обращаюсь в блайде через route(''), генерирует норм, когда перехожу по адресу ошибка 404
https://paste.laravel.io/77d29964-38e8-4197-8d05-6dd07cb971e5
http://portfolio.loc/skills/1/edit
https://paste.laravel.io/77d29964-38e8-4197-8d05-6dd07cb971e5
DM
Но да, тоже склоняюсь к статусам в enum и константам.
UB
Я влезу тут, выше описал минус, точнее даже не минус, а нюанс.
Так вот при таком подходе раз в какое-то время шедулер должен запускать скрипт, который будет проходить по базе и менять статус, чего хотелось-бы избежать (база может стать большой). А в случае если это виртуальное поле, то оно считается динамически основываясь на других полях. Т.е. явно статуса нет, но по савокупности данных в разных полях ацессор вернёт статус. Но блин, как-то тоже сомнительно.
Не понял если честно
AH
Назови минусы такого варианта?
Легко!
В сервисе тебе нужно проверить находится ли элемент в статусе "Foo". Для этого будешь вызывать
Нужно их либо вынести в отдельный файл, например,
В сервисе тебе нужно проверить находится ли элемент в статусе "Foo". Для этого будешь вызывать
$item->status === Ticket::STATUS_FOO, где Ticket - модель, а брать ее константы дерьмецом попахивает.Нужно их либо вынести в отдельный файл, например,
App\Constants\Statuses::FOO, либо в конфиг, например, config('tickets.statuses.foo')UB
Я влезу тут, выше описал минус, точнее даже не минус, а нюанс.
Так вот при таком подходе раз в какое-то время шедулер должен запускать скрипт, который будет проходить по базе и менять статус, чего хотелось-бы избежать (база может стать большой). А в случае если это виртуальное поле, то оно считается динамически основываясь на других полях. Т.е. явно статуса нет, но по савокупности данных в разных полях ацессор вернёт статус. Но блин, как-то тоже сомнительно.
Сам статус хранится в базе. Тайтл в константе. Как это противоречит щедулеру?
IG
сам список роутов
AH
Я влезу тут, выше описал минус, точнее даже не минус, а нюанс.
Так вот при таком подходе раз в какое-то время шедулер должен запускать скрипт, который будет проходить по базе и менять статус, чего хотелось-бы избежать (база может стать большой). А в случае если это виртуальное поле, то оно считается динамически основываясь на других полях. Т.е. явно статуса нет, но по савокупности данных в разных полях ацессор вернёт статус. Но блин, как-то тоже сомнительно.
+