Первая реализация репозиториев возвращала в getList() массив элементов и это работало. Сейчас пришло понимание что пагинацию не сделать так.
Думаю переделать массив на коллекцию с итератором в которой будет параметр "totalCount", ну вы поняли.
В общем, реализовал отдельный класс Collection (наследник от базовых массивов и т.д.) который возвращается в методе getList, коллекция имеет $totalCount. Так сделал потому что так сделано в magento 2 и считаю это правильным.
Все же репозиторий не коллекция.
Михаил Шатилов, тут все довольно однозначно. Если и вас репозиторий - не коллекция, то и репозиторием его называть не стоит. Назовите его как-нибудь по другому, DAO например.
galliard, не знаю, возможно я и ошибаюсь. Судя по первой статье на хабре разница между ними в манипулировании сущностью вместо подробностей в репозитории, ну и отсутствии findByUsername. Да и шаблон не имеет реализации коллекции.
Или вот symfony. Репозиторий в их понимании возвращает return array The objects.
Нигде не видел чтобы было return $this в find().
Вы, видимо, под коллекцией подразумеваете некую конкретную реализацию, но это просто класс, описывающий некое множество сущностей.
Однако это не обязательно единственная коллекция в проекте, просто наиболее общая. Так что $this ей возвращать не нужно достаточно вернуть подмножество сущностей, удовлетворяющих заданному условию.
Это я к тому, что создавать коллекцию, которая будет содержать например 30 сущностей и ещё иметь поле totalCount со значением например 180 - не правильно, потому как никаких 180 сущностей в ней нет, а есть только 30. А 180 есть в репозитории, поэтому логично запросить эту цифре из него.
elementRepository.Count - репозиторий это абстракция над базой данных, ее можно воспринимать как простую коллекцию, ну т.е. иметь операции добавления/удаления/поиска...
А вообще, если вы используете пагинацию, то значит вам нужны данные для отображения информации, а для этого тянуть из базы агрегаты не очень хорошая практика... Замените их на ViewModel и эти простые DTO'шки тяните из БД
