• Какую архитектуру выбрать для сайта объявлений?

    @jazzus
    Таблица users содержит только поля пользователей.
    Таблица companies содержит только поля компаний и + поле user_id для связи с пользователями.
    Юзеров связываем с компаниями c помощью связи hasMany (имеет много). Т.к. пользователь может иметь много компаний. Если непонятно гугли hasMany.
    Объявление публикует юзер, делаешь поле в форме - "От компании" и выбор компаний пользователя из списка.
    Таким образом у тебя пользователь может публиковать и от себя, как физлица, и от любой своей компании.
    Ну а в самом объявлении проверяешь, заполнено ли поле "От компании" и если заполнено то показываешь данные компании.
    Ответ написан
    Комментировать
  • Обычные vs полиморфные отношения, какие выбрать?

    @jazzus
    Конечно полиморфные. А если 15 сущностей имеют картинку (что запросто может быть) - 15 айдишников прописывать в images, затем 15 belongsTo отношений в модели? Не лучшая идея. Удобней трейт HasImage с отношением morphOne image, подключенный у всех моделей. Единственная "сложность" это контролировать удаление картинки при удалении модели, но тебе итак нужно удалять картинку, как минимум с диска. Зацепить при этом модель одна строчка. В том же трейте HasImage прописал один раз логику в методе deleteImage и там this->image->delete, а сам метод вызывать в обсервере у модели при удалении. И всякие сервисные методы типа получения ссылки на изображение и т.д. Все в одном трейте. Сэкономлена тонна кода. Только в случае картинок я бы сразу сделал много картинок у сущности т.е. morphMany, что не помешает тебе брать одну. Т.к. где morphMany images может быть и morphOne image. А лучше вообще одну таблицу файлов т.к. какая разница какие файлы картинки это или документы - у всех одна логика загрузки, удаления и тд.
    Ответ написан
    1 комментарий
  • Где можно скачать готовое API на Laravel?

    @jazzus
    Проекты на Гитхабе стоит смотреть только для расширения кругозора. Учиться по чужим велосипедам точно не стоит. Там много треша и у всех разные цели. Поэтому пример для подражания нужно брать в документации Ларавел. Там все разбито по разделам, охватывающим части вебприложения. Внедряться в каждый и разбираться. А с чужого велосипеда слезать потом тяжело будет и смысла не имеет.
    Ответ написан
  • Можно ли получить уже забинженную модель в форм-реквесте?

    @jazzus
    $user = $this->route()->parameter('user');
    Ответ написан
    Комментировать
  • В какой стране проще получить торговый эквайринг для приема платежей?

    @jazzus
    Payture принимают карты по Европе кроме Украины. Я думаю, если поискать можно и США найти.
    Ответ написан
    Комментировать
  • Как улучшить контроллер, метод, архитектуру?

    @jazzus
    В первую очередь нужно использовать сервисы Ларавел. Они очень хорошо работают и постоянно улучшаются. См документацию. Далее свои классы, но не просто "тупо выносить код в сервис", а разделять классы на задачи. Все не нужно выносить в сервис, т.к. тогда без разницы, что засирать - контроллер или сервис. Лучше тогда простыня в контроллере без доп файлов. Разделяй классы на логические действия, чтобы их можно было изолированно переиспользовать. Нужно активировать юзера со сложной логикой? Класс UserActivate, который ты можешь использовать в разных местах. А не UserService, который и активирует, и удаляет, и ничем от простыни в контроллерах не отличается. Жизнь тебе не упрощает. А UserActivate упрощает, делает код легким в поддержке/рефакторинге, понятным для человеческого глаза и чистым. В такое приложение можно быстро вносить изменения, а не разгребать простыни. Простыни не из-за феншуя не любят, а потому что поддерживать их с ростом приложения все труднее. Простые по функционалу приложения превращаются в "сложнейший проект". Поэтому сервисы обязательно, но в первую очередь классы Ларавел, т.к. они покрывают большую часть потребностей.
    Ответ написан
    Комментировать
  • Laravel проверить есть ли запись в избранном, как решить проблему?

    @jazzus
    В Ларавел это делается очень просто с withExists. Можно не писать простыни джоинов.
    Ответ написан
  • Как лучше разбить на сущности?

    @jazzus
    Film
    id
    name
    film_type_id

    FilmType (Полный метр, Короткий метр, Сериал)
    id
    name

    Episode (серии)
    id
    name
    film_id
    season_id

    Season
    id
    number
    year
    Ответ написан
    Комментировать
  • Как дела с реактивностью у Laravel Livewire?

    @jazzus
    Livewire - шляпа. Там половина Ларавел за бортом и много других моментов (кривые тесты, мало юзкейсов в гугле, засранный бэкенд итд). Думал Inertia также, оказалось нет. Сейчас юзаю на проекте Inertia Vue в пакете Laravel Jetstream - отличная замена монолиту с эффектом спа) Процесс оптимизирован, всё продумано, пакеты подключены и работают (c ziggy пишешь роут нейм прямо в vue c автокомплитом в шторме), витя компилит быстро, вопросов к сборке не нашлось. Tailwind останавливал некоторое время, но и он норм оказался (если на компоненты делить т.к. куча классов ухудшают читаемость).
    Ответ написан
    Комментировать
  • Идея сервиса по шерингу вещей. Успех или провал?

    @jazzus
    Хорошая идея, а вот исполнение (сайт) не очень.
    Ответ написан
  • Как можно оптимизировать запрос?

    @jazzus
    Смысла указывать where('id', $order->id) для уникального id нет. У тебя там будет одна запись, которая итак есть в переменной $order. Если нужно подгрузить отношения к $order нужно юзать load:
    $order->load([
        'user' => function ($builder) {
            $builder->select('id', 'name');
        },
        'orderItems' => [
            'ingredients', 'options', 'product'
        ]
    ]);

    Хотя лучше просто сохранить отношения в переменные (исключая отношения orderItems)
    Ответ написан
    Комментировать
  • Как сгруппировать несколько обработчиков AJAX запросов в одном контроллере LARAVEL?

    @jazzus
    Как связаны какая-то там CMS и фреймворк Ларавел? В Ларавел свой метод работы и архетиктура. Роут-метод контроллера-фронт. РКФ. Один роут вызывает один метод контроллера, который обрабатывает запрос и отдает результат. Непонятно, как работает - значит нужно изучить, а не пилить костыли.
    Ответ написан
  • Вопрос о тестах. Что вы об этом думаете?

    @jazzus
    Фабрики уберут, Ларавел отменят, PHP закроют. Нужно срочно все изолировать пока лицензии не отобрали и не навязали принудительное обновление. Всё прячем в говнокод.. Ты можешь юзать сгенерированные данные, если логика теста это позволяет. и не toArray, а указать в структуре конкретного запроса. Если по счастливой случайности у тебя пока модель совпала с запросом, то это не значит, что фабрика/логика/модель не будут меняться и тесты не начнут неэффективно падать на пустом месте, тупо изза данных реквеста, которые ты не контролируешь. Нужна изолированность и точность. Минимум автоматизации и универсальности. Бд обязательно сносить перед каждым тестом (юзать трейт). Конечно, это если ты собираешься писать много тестов и нормально работать с ними (тдд например). Если 1 тест ради теста, шлепнуть пост запрос, то вообще все равно как его писать и поддерживать, можно смело генерировать структуру запроса из фабрики целиком или еще что-нибудь придумать.
    Ответ написан
    Комментировать
  • Как удалить запись в сводной таблице по ее идентификатору?

    @jazzus
    Pivot модель, вложенный ресурсный контроллер с shallow и
    public function destroy(OrderDish $orderDish)
    {
          $this->authorize('delete', $orderDish);
    
          $orderDish->delete();
    
          return back(303);
    }
    Ответ написан
    1 комментарий
  • Как правильно реализовать систему рейтинга?

    @jazzus
    Таблицы для рейтинга и критериев. Отзывы будут иметь много рейтинга, которые будут принадлежать критериям. Получать с помощью withAvg.
    Ответ написан
  • В чем преимущества Route Model Binding?

    @jazzus
    1) В твоем случае вообще нужно юзать ресурсные роуты, которые работают с биндингом, а это еще минус строки кода. Далее тебе нужно проверить права доступа, а значит политики авторизации, с ресурсными контроллерами, это еще минус код тк они конектятся одной строкой кода ко всем методам и модель через биндинг передается автоматом в политику. А в этом и есть смысл фрейморка - не писать код самому и не пилить кривые велосипеды.
    2) Модель тебе может понадобиться в мидлварях, форм реквестах, политиках, с биндингом тебе не нужно делать на каждом этапе свои одинаковые запросы.
    3) Что такого в load неудобного не понял? Тот же самый with.
    4) если ты проверяешь права доступа к модели, то тебе обычно не нужны ее отношения и поэтому нет смысла их грузить до проверки в политиках - это будут лишние запросы если авторизация не прошла. Для этого биндинг дает именно то, что тебе надо - чистую модель.
    5) Where в модели не нужен. То, что ты проверяешь статус в модели - это проверка доступа, которую нужно делать в политике.
    6) Удобно, красиво, быстро и необходимо для полноценного использования Ларавел, а не только роуты, контроллеры и вьюхи как в 99% проектов.
    Ответ написан
    4 комментария
  • Как достать parent_id?

    @jazzus
    whereNull parent_id
    Ответ написан
    Комментировать
  • Вход/регистрация на laravel?

    @jazzus
    Стартовые наборы https://laravel.com/docs/9.x/starter-kits. Jetstream с фронтом (vue и inertia). Там будет в добавок профиль пользователя. Для ролей пакет spatie roles и политики авторизации.
    Ответ написан
    Комментировать
  • Объеденить 2 модели при выводе?

    @jazzus
    Конечно, только одна таблица. Для статей articles, для юзеров users, для ролей roles. Такое говнопроектирование оставлять нельзя. А заказчику объяснить, что без исправлений все последующие костыли и время-цена доработок будут по нарастающей.
    Ответ написан
    Комментировать