По поводу 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 в цикл, вместо того чтоб выбрать нужные данные перед циклом и потом копаться уже в массиве или коллекции. Хотя ситуации бывают разные как говорится =)
Laravel по-русски
По поводу 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 в цикл, вместо того чтоб выбрать нужные данные перед циклом и потом копаться уже в массиве или коллекции. Хотя ситуации бывают разные как говорится =)