Некорректная формулировка и искажение изначального смысла. Что значит «действие»? Класс должен всегда иметь ровно один метод?
Здесь неясно почему твой «бизнес-сервис» принимает на вход HTTP-request. Бизнес-сервису обязательно знать по HTTP или по какому другому протоколу был загружен файл?
Это искажение смысла принципа и следование такому совету откровенно вредно. DRY — это не про код, а про недвусмысленность и непротиворечивость. Абсолютно нормально иметь дублирующиеся (и возможно даже copy-pasted) куски кода, если они на самом деле не представляют из себя одно целое, а просто случайно совпадают.
Откровенная чушь, которая уже обсуждалась на форуме, но ты просто молча слился без каких-то аргументов, а теперь навязываешь свои религиозные догмы новичкам.
Согласен. Можешь предложить что-то лучше, чем "каждый класс и метод должны выполнять лишь одну функцию"?
Соглашусь, но я пытался упростить код, чтобы любой мог его понять. Суть примера не в этом и не в public_path('images') . 'temp', что тоже плохо. Но я все-таки исправил код.
Перешел по ссылке и я не вижу, чтобы мы это обсуждали. И я не вижу "слива". В теме человек задал вопрос, я и AmdY ему помогли. Остальные вместо помощи обосрали Eloquent, отправив лепить велосипеды и использовать сырые запросы.
Есть классическое определение про only one reason to change. Да, оно непросто для понимания и его надо осмыслить, но без осмысления все равно ничего не получится.
А если цель - донести каждому джуну, то как лучше сформулировать принцип?
Ньюкласс ньюклассу рознь.
Вот именно, User это в первую очередь сервис, а не сущность, потому DI нужно. При использование вендоров меня как раз спасала возможность DI подсовывать разные инстасы через when-needs-give.
Мокается на ура. С DI можно и dummy класс инжектить. Чего нельзя делать с new User.
User чаще и выступает в качестве репозитория. Используется как $this->user->getActiveLawyersWithContracts(). С самых крупных Laravel проектах, которые я видел, тот же подход.
Вот не понятно что лучше
interface UserRepository {...}
class UserRepository implements UserRepository {
public function find($id): User {
return User::findOrFail($id);
}
}А там точно static? Вон выше рассказывают, что он «мокается на ура».
Не совсем, конечно. Там немного через задницу:
/**
* Handle dynamic static method calls into the method.
*
* @param string $method
* @param array $parameters
* @return mixed
*/
public static function __callStatic($method, $parameters)
{
return (new static)->$method(...$parameters);
}
/**
* Handle dynamic method calls into the model.
*
* @param string $method
* @param array $parameters
* @return mixed
*/
public function __call($method, $parameters)
{
if (in_array($method, ['increment', 'decrement'])) {
return $this->$method(...$parameters);
}
return $this->newQuery()->$method(...$parameters);
}
Все крупные проекты на ларавель, которые я видел - авгиевы конюшни.
Мы так и делаем. Но с элоквентом очень трудно. Говоришь ему брать эту сущность из Write базы. Все ок. Но пытаешься взять relation - эта скотина его берет из Read базы! Плюс оно не персистит релейшены... надо самому руками все. Я всерьез подумываю начать некоторые write модели переводить на Doctrine.
Поэтому и имеете проблемы, половина SO засрана подобными вопросами. Одна из хороших практик, которую я описал в репо - это забыть о великах и использовать стандартные инструменты и практики. Не нравится Eloquent, почему не использовать Symfony? Такой подход (избегание великов) сэкономит мешок денег клиенту.
Ну ты конечно много знаешь о сэкономленных мешках денег
переписывать проект на другой фреймворк никто не станет. А изначально выбрать что-то правильное, часто не хватает квалификации. Люди бегут на хайп.А что это за религиозный подход «принять целиком или отказаться полностью»? Тут выбор не между Библией и Кораном, это два набора отвёрток. Какие-то можно взять отсюда, какие-то — оттуда. А уж смотреть в рот разработчикам Laravel и их приближённым и считать их слова истиной в последней инстанции по тому как пользоваться их набором отвёрток — нет, спасибо, я не чувствую в этом потребности.
Кое что знаю, по крайней мере нанимают конкретно с целью сэкономить пару мешков. Зачем пытаться унизить?
Если Eloquent действительно ставит палки в колеса, это недоработка CTO или лида. Инструмент выбрали неправильно. Но я в этом сомневаюсь, не видел ни одного проекта, где бы Eloquent заменили на что-то другое. Видел десятки коммерческих проектов и больше сотни Laravel проектов, если считать то, что присылают кандидаты для оценки.
Мы уже спорили по этому поводу на этом форуме и меня зачморили тогда за мои взгляды. Но я все еще придерживаюсь того же мнения.