Ты не ответил. Вопрос звучит как "В чем конкретно преимущество использования репозитория при работе с Eloquent?". Есть класс User, есть класс UserRepository. В чем преимущество использования лишней абстракции в виде класса UserRepository: Код (Text): return User::with('articles')->get(); Перед вызовом метода модели: Код (Text): return $this->with('articles')->get; Ты совсем не видишь разницы между count() коллекции и count() Query Builder'а? Ты неправ и всеми силами пытаешься унизить снисходительным тоном и прочей демагогией и пр., лишь бы не признать этого. --- Добавлено --- Эго задел? Пусть будет уборщик.
Ну Алексей, я тебе тоже пытаюсь объяснить. Ну откуда-то в коллекции должны взяться элементы, чтоб она их могла посчитать, найти минимум, максимум или ещё что-то? Если они изначально в базе лежат, то в коллекцию их надо загрузить, а Eloquent в конце концов транслируется в SQL.
А ты не сумел простой, реально очень простой SQL запрос, выразить на AR. 1:1 Разница в том, что я и не пытался утверждать, что А лучше Б. Я утверждал: А не является Б. > Демагогия — набор ораторских и полемических приёмов и средств, позволяющих ввести аудиторию в заблуждение и склонить её на свою сторону, с помощью ложных теоретических рассуждений, основанных на логических ошибках (софизмах). И вообще, вопросы здесь задаю я Ты опубликовал здесь ссылку саморекламного характера, так будь добр защищать её ценность. --- Добавлено --- Я должен признать свою ошибку: в первом в своём каменте я писал "автор намеренно составил корявый SQL запрос". Сейчас я верю, что это было сделано ненамеренно. Извини!
Я это понимаю прекрасно, я там гружу аппойнтменты для каждого менеджера. Но я же несколько раз озвучил бизнес задачу для своего кода и предложил придумать реальную бизнес задачу, чтобы написать Eloquent и SQL запросы для нее. Но вон artoodetoo до сих пор тычет мордой в тот запрос, не имеющий ничего обего с решением реальных бизнес задач. Сейчас же мы говорим о 1 + N*3 и N+1. @artoodetoo с тобой все понятно, ты пришел с phpклаба и сеешь тот же навоз здесь. Можешь удалить тему, бог тем. Я почти уверен, что переживу это. Адекватный человек в разговоре отвечает на вопросы и приводит аргументы, но не занимается тем, чем занимаешься ты.
На phpclub мне самому прилетало по башке (но я зла не держу), так что я не оттуда. Ты в упор не видишь аргументов, хотя мы их уже несколько раз повторили, я уже не знаю что сказать. Злость мешает тебе думать, это печально.
ой, опять холивар развели на пустом месте. Всё это херня, господа. Главное в нашем деле - это заложить возможность горизонтального масштабирования в архитектуру приложения. Остальное - мелочи ))
Брат, так вроде никто тебя не просил писать свою "бизнес задачу". Я тебя спросил сможешь ли ты адекватно переписать запрос SQL на Eloquent. Ведь ты защищаешь тезис, что хорошей практикой является именно ЭТО. --- Добавлено --- золотые слова! главное хайп, он хорошо продаётся.
Надеюсь автор ещё тут ) В Laravel, вроде с 5.2 в Builder добавили метод cursor() возвращающий генератор, который можно итерировать для получения записей. Как известно, кроме того что он круто выглядит, он ещё и быстрее и экономнее к памяти. При этом упоминается он небольшим разделом в документации и во всяких best practices чуть более, чем ни разу. Код (Text): Выборка всех записей, немного действий с ними, короче, все как обычно бывает. Машинка там очень слабенькая впска, с фоновыми тасками, удаленная, записи сами по себе большие, да ещё и под виндой всё, не прогрето ни разу, потому такие тайминги. Не суть, короче. Главное тут пропорции. Всего записей: 17323 ->all() Память (разница): 20 971 520 Время от старта: 0.26321697235107 ->chunk(3000) Память/пик (разница): 11 376 432 Память (разница): 73232 Время от старта: 0.30519890785217 ->cursor() Память (разница): 804 672 Память/пик (разница): 812 936 Время от старта: 0.23832893371582