lukoie, это шутка? Мне даже интересно сколько времени вы потратите, что бы сэкономить десять рублей на 500мб места... Или вы думаете что много таких людей, которым не влом таким заниматся?
ambrozimikoni, заказчик в любой момент может сказать, что хочет на свой бложик еще и бар со шлюхами. Будете переписывать еще раз бложик? Зачем, если можно сразу написать хорошо? Это займет у вас столько же (если не меньше) времени, а вам же потом меньше проблем.
Причем тут иньекции и брутфорс к игровым серверам? Если вы именно об защите сервера (а не сервер от игры, который софтверный) - ставьте fail2ban. Если об сервере от игры, который софтверный - его защищать не нужно. Если в нем есть баги, то их только разработчики поправить могут, ибо обмен происходит с помощью пакетов, которые понимает только эта самая игра, и никакие "общие" решения (как, например, связанные с вебом) - тут не помогут. Но если игра популярная - можете не волноватся.
Я не профи, и все же: в случае Eloquent - нет, не стоит. Лично я использую архитектуру Porto, и вместо репозиториев использую "таски" - классы, выполняющие ровно одно действие. Для простоты можно представить, что каждый таск - отдельный метод в сервисе, в обычной сервисной архитектуре. Так вот, если правильно ее использовать, в конечном итоге у вас точно будет несколько тасков, которые только то и делают, что проводят манипуляции с БД.
1) нету смысла делать таск, который инжектит репозиторий а потом просто вызывает метод из репозитория. Почему бы не использовать сам таск для хранения логики?
2) иногда приходится писать некую логику с киданием эксепшенов прямо внутри транзакций (функции, которая в DB::transaction() передается). Например, есть таск "отнять у юзера $user $amount денег", и я бы хотел получить InsufficientFundsException в случае, если у юзера не хватает их. Это не совсем задача репозитория, но в тоже время мы никак не сможем вынести оттуда эту логику..
На счет "менять тип данных" - нет, оно то может выйти (на выходе - интерфейсы, на входе - отдельные входные переменные), но я не вижу смысла. Если уж вам так захочется перейти на Doctrine (единственный доступный вариант), то отрефакторить проект, наверное, будет проще, чем каждый раз описывать интерфейсы, использовать репозитории и так далее. Не стоит оно того.
Пока что репозитории мне еще ни разу не пригодились - лучше правильно строить логику и разделять ее на методы (таски).
ponaehal, использую так же, как хотел использовать max(), работает отлично. Тут дублирования нет, но если делать так, мне прийдется вытянуть нужные параметры один раз, а потом еще и для max(), а их там больше чем два).
Значения max_fast_jackpot и max_coinflip_jackpot мне нужны и в других рассчетах. Я использую их спокойно с операциями *, +, -, а дублировать еще раз их - не вариант (
Вадим, я не сишник, но попытаюсь обьяснить: что значит "выполнила два"? В функцию передаются все аргументы и после этого она делает свою работу. и.е. min(1, 2, 3) - вызов функции с тремя аргументами, и это не min(1); min(2); min(3);
А вот в случае с min((1, 2, 3)) - это min(3), потому что сначала рассчитывается значение скобок внутри - "(1, 2, 3)" - результат чего равен 3. Собственно подставляем вместо "(1, 2, 3)" результат и выходит просто "3", а следовательно и min(3).
Скобка впритык около вызова функции - начало списка аргуметов, ну и парная ей - конец этого списка. А вот внути уже может быть что хотите, любое выражение, и "(1, 2, 3)" - именно выражение.
Антон Алексеевич, то, что они схожи - не значит что одинаковые. Сущность комментария - это одно, сообщение в чате - совсем другое. Две разные модели, даже если поля были б полностью идентичны.
alex-1917, я знал что кто-то да так напишет. Дело в том, что я ответил на все вопросы автора, но вы, судя по всему, решили прочесть только последнюю строчку.
Inclusive, логично, если использовать интерфейс. Но это уже, имхо, overcomplication - очевидно, что у этого интерфейса всегда будет только одна реализация, и реально профита он вам не даст. А фигачить его просто что бы красиво было - можно, конечно, но, имхо опять же, это только усложнит разработку в дальнейшем (лазить в интерфейс и в модель, напичканную магией, дабы изменить/добавить метод - такое себе удовольствие).
А на счет рефакторинга - исключений много, и скоупы - одно из них. Да, тут интерфейс пригодится. Но так ли оно вам надо? Я бы лучше избавлялся от магии в моделях, например использованием Doctrine или репозиториев, ежели поверх и так странноватенькой системы пилил костыли. Ну, опять же, это мое имхо только.
Inclusive, ок, был не прав на счет with. Мне казалось, что там только phpdoc, а сам метод, как и все остальные, просто создают query builder и дергают нужный метод на нем, и.е. User::where() и тд.
Не пойму о каких методах вы говорите. Об квери методах? Нет, они в квери-билдере eloquent'овском. Скоупы? Их так-же как-то либо моделька, либо квери-билдер вызывает. Релейшены? Другие методы, которые именно к реальным данным привязаны? Ну тоже не имеет отношения к этому. А еще каких-то методов там не будет. И не пойму что за filterParams - это уже либо к репозиторию, либо в скоуп.
Опять же не пойму зачем что-то везде менять, если в современных IDE, если вам очень захотелось поменять название метода/класса, есть рефакторинг автоматический =/
И не вьезжаю, зачем что-то менять по проекту после, цитирую, "написания обновленной модели"? Чем инжект и (new User)->newQuery()->whatever() отличается от User::whatever() с этой стороны? Что там что там скоуп whatever IDE, понятное дело, не сможет отрефакторить, и я не вижу какие преимущества это вам дает.
Inclusive, с каких пор статика - это магия? User::with - это уже магия, staticCall вызывает, а query - существующий метод в классе.
В том примере с DI в конструкторе, следуя логике, вы инжектите инстенс модел, то есть конкретный ее экземпляр, а не инстенс квери-билдера/энтити-менеджера. Правильным решением будет вообще не использовать такую бредятину вместе с Eloquent. А с Doctrine такого вообще не выйдет.
Или совсем на крайняк, если очень хочется использовать именно $hidden, то можете скостылить свой BaseJsonResource, где напишите один метод whenNotHidden - но это плохое решение. Используйте второе и упростите себе жизнь в дальнейшем)
Спасибо за инфу про масла, как раз выбирал стол.