DM
А, т.е. вкусовщина)
Size: a a a
2020 February 25
DM
ну, точнее зависит от величины проекта скорее
DM
По контроллерам смотри. Например, есть два возможных состояния: магазин закрыт и магазин открыт. В каждом из состояний свой набор правил обработки заказов и он отличается друг от друга. Таким образом, вызов того или иного метода сервиса должен осуществляться именно в контроллере.
Например:
Например:
$shop = $shop->is_open
? app(OpenedService::class)
: app(ClosedService::class);
$result = $shop->get();Похоже, это и есть логика приложения и её отличие от логики домена (бизнес логики)
A¯
не в филлабл значит это пол
есть это поле в филабле
role_id но не обновляется
role_id но не обновляется
User::firstOrCreate(['email' => 'user_1@test.com'],
[
'name' => 'user_1',
'email' => 'user_1@test.com',
'password' => bcrypt('secret'),
'remember_token' => str_random(60),
'role_id' => 1,
]);
ML
есть это поле в филабле
role_id но не обновляется
role_id но не обновляется
User::firstOrCreate(['email' => 'user_1@test.com'],
[
'name' => 'user_1',
'email' => 'user_1@test.com',
'password' => bcrypt('secret'),
'remember_token' => str_random(60),
'role_id' => 1,
]);
В данной конструкции она не должна обновлятся
ML
тебе просто запись с почтой user_1@test.com вернется если таковая существует
ML
если нет, создаст
ML
Со второго аргумента можешь убирать ключ email, она их мерджит в итоге все равно
A¯
В данной конструкции она не должна обновлятся
Так как обновить role_id
ИС
есть это поле в филабле
role_id но не обновляется
role_id но не обновляется
User::firstOrCreate(['email' => 'user_1@test.com'],
[
'name' => 'user_1',
'email' => 'user_1@test.com',
'password' => bcrypt('secret'),
'remember_token' => str_random(60),
'role_id' => 1,
]);
User::firstOrCreate(['email' => 'user_1@test.com'],
[
'name' => 'user_1',
'password' => bcrypt('secret'),
'remember_token' => str_random(60),
])->update(['role_id' => 1,])
[
'name' => 'user_1',
'password' => bcrypt('secret'),
'remember_token' => str_random(60),
])->update(['role_id' => 1,])
DM
https://emacsway.github.io/ru/service-layer/
Годно, грань между сервисами домена и сервисами уровня приложения действительно очень тонкая
Годно, грань между сервисами домена и сервисами уровня приложения действительно очень тонкая
A¯
User::firstOrCreate(['email' => 'user_1@test.com'],
[
'name' => 'user_1',
'password' => bcrypt('secret'),
'remember_token' => str_random(60),
])->update(['role_id' => 1,])
[
'name' => 'user_1',
'password' => bcrypt('secret'),
'remember_token' => str_random(60),
])->update(['role_id' => 1,])
Работает спасибо
ИС
Работает спасибо
Вчера не до конца понял твою задачу, сори)
M
Завтра Адам начнёт продавать свой бутстрап, т.е. TailwindUI за 150/250 баксов https://vimeo.com/393580241/82c6d7c5f6
AH
да и php artisan cache:clear - не занимает столько времени сколько перекомилить весь фронт
Глянул твою статью (https://t.me/laravel_web/198448).
Дак ты ж там файлы локализаций грузишь. Поэтому при деплое проекта так или иначе нужно собирать фронт. В связи с этим непонятна твоя сложность с этой задачей. Зачем придумывать такие велосипеды, когда можно взять готовое решение?
Дак ты ж там файлы локализаций грузишь. Поэтому при деплое проекта так или иначе нужно собирать фронт. В связи с этим непонятна твоя сложность с этой задачей. Зачем придумывать такие велосипеды, когда можно взять готовое решение?
M
Пример лэндинга на нём: https://tailwindui.com/page-examples/landing-page-01
Надо брать
Надо брать
D
Michael
Пример лэндинга на нём: https://tailwindui.com/page-examples/landing-page-01
Надо брать
Надо брать
прикольно
AH
тогда по сути, если я всё верно понял, OrderService это не совсем конкретно и понятно, и вообще получится божественный класс, если сервис будет делать ВСЁ что касается Order-а. Тогда, наверное, лучше разбивать например на ShopScheduleService, OrderAcceptanceService и т.д.?
Зависит от объема. Тот же NetBeans рекомендует максимальный размер класса в 227 (если память не изменяет) строк.
А вообще, если логика не принадлежит различным, скажем так, сущностям и семантике, то стоит всё держать в одном месте.
А вообще, если логика не принадлежит различным, скажем так, сущностям и семантике, то стоит всё держать в одном месте.
AH
Похоже, это и есть логика приложения и её отличие от логики домена (бизнес логики)
Это, скорее, контролирующая логика - проверка запуска обработки той или иной бизнес-логики (сервиса) в зависимости от условий.
4
Глянул твою статью (https://t.me/laravel_web/198448).
Дак ты ж там файлы локализаций грузишь. Поэтому при деплое проекта так или иначе нужно собирать фронт. В связи с этим непонятна твоя сложность с этой задачей. Зачем придумывать такие велосипеды, когда можно взять готовое решение?
Дак ты ж там файлы локализаций грузишь. Поэтому при деплое проекта так или иначе нужно собирать фронт. В связи с этим непонятна твоя сложность с этой задачей. Зачем придумывать такие велосипеды, когда можно взять готовое решение?
Понимаю. До этого я юзал другой пакет, который все это уже делал. Но нужно было пересобирать фронт чтобы измененные фразы (language string или как их еще называют?) загрузились.
Клиент потихоньку сам переводит фразы. Есть пакет для ларки + нова пакет, который и json и php фразы умеет изменять. можно добавлять новые фразы и тп.
проблема в том, что после того как клиент добавил фразы - они не будут отображаться в js файлах (vue компонентах и тп), поэтому ему надо пересобирать фронт - что не очень удобно
Клиент потихоньку сам переводит фразы. Есть пакет для ларки + нова пакет, который и json и php фразы умеет изменять. можно добавлять новые фразы и тп.
проблема в том, что после того как клиент добавил фразы - они не будут отображаться в js файлах (vue компонентах и тп), поэтому ему надо пересобирать фронт - что не очень удобно