В представлении AR
Model = Таблица
экземпляр Model = запись из таблицы,
что мешает получать записи по одной в цикле из нужной таблицы и записывать в массив. На выходе получается массив или коллекция. Собственно современные ORM это и делают.
Например получение всех записей из таблицы категорий (модель Categories) в большинстве современных фреймворков выглядит примерно так:
$categories = Categories::all()
На выходе в переменной $categories получаем коллекцию (по сути массив каждый элемент которого является объектом модели Categories):
Collection {#168 ▼
#items: array:5 [▼
0 => Categories {#169 ▶}
1 => Categories {#170 ▶}
2 => Categories {#171 ▶}
3 => Categories {#172 ▶}
4 => Categories {#173 ▶}
]
}
Вы можете пробежаться по этому массиву и получить нужную запись. Никаких проблем.
Утрированно:
Controller - управляет.
Если это Посты, то ими надо управлять, действовать. Методы (actions, действия) работы с Постами, например create, delete, update, edit. Логично было бы предположить что для управления Постами нужен PostsController.
Комментарии - свой набор действий (action) логично предположить что для них следовало бы сделать отдельный контроллер CommentsController, который содержал бы логику управления только Комментариями, а не всем на свете(например Пользователями). Вы всегда будете знать что Комментариями управляет CommentsController, Постами - PostsController. Более того, если кто-то другой откроет ваш код, то он сделает логичное предположение, что за Посты у вас отвечает PostsController и начнет работать/ломать оттуда.
Не зацикливайтесь сильно на теории. Пишите код, и чаще выводите var_dump()-ом промежуточные результаты, вы будете видеть как устроено данные, и начнете понимать как к ним подобраться.
Создайте объект класса (Модели), сделайте запрос, выведите дампом и посмотрите как устроены данные. Вы наглядно увидите объект это или массив, или ни то, ни другое, ни третье )).
