| Laravel по-русски

Статистика: Символов — 1 672/1 405 без пробелов (1 672/1 405 без кода):, слов — 268
Разметка: Wiki
По поводу collection vs array, например - https://www.reddit.com/r/laravel/comments/44a2p2/laravel_collection_vs_array_performance/

Логично, что коллекция будет отъедать перфоманс - за удобство приходится платить. Но опять таки, как правильно пишут люди, если вы перебираете коллекцию на миллион записей, у вас что-то неправильно в sql. 

По поводу вьюх и моделей мое мнение, что слой БД отдельно, слой представлений отдельно - не должны вьюхи обращаться с БД. Если уж никак не позволяет ситуация разрешить создание данных в контроллере, то значит нужен какой-то компонент (сервис) для вьюх. Но лучше решать это на уровне контроллера, сервисов. В некоторых случаях можно наверное для удобства сделать модели данных (не Eloquent). Вобщем  ситуации бывают разные, но вьюха к бд не обращается - неправильная архитектура.

Да и в целом, многие понимают паттерн MVC слишком буквально как по мне. Холивары "тонкий контроллер-толстая модель" и наоборот гремят с неослабевающей силой. Но как по мне, тонкими должны быть оба - single responsibility. А контроллер распределяет логику между сервисами (компонентами), ивентами и пр. частями приложения и отдает уже полученные от них данные в виде переменных во вьюху. Напрямую контроллер у меня не часто "знает" про модель.

Что касается "жадных загрузок", вьюх, Eloquent - вообще если данные будут использоваться в цикле (не только вьюха), то конечно только "жадная". Миллион не миллион, но даже  например 500 обращений к БД в цикле - уже караул какой-то (а 500 ведь не предел). Но это понимание наверное придет с практикой, некоторые например запихивают какой-то select в цикл, вместо того чтоб выбрать нужные данные перед циклом и потом копаться уже в массиве или коллекции. Хотя ситуации бывают разные как говорится =)