Действия с несколькими записми в базе

Назрел следующий вопрос по архитектуре приложения: где расово верное место для определения методов для работы с несколькими записями в базе данных? Например, нужен метод getActiveUsers(), который выберет из базы всех активных пользователей. Понятно, что логично расположить его в соответствующем контроллере. Но если такой метод нужен в нескольких контроллерах? Проще всего написать статический метод в модели - User::getAllActive(), но это выглядит неправильно с точки зрения архитектуры - все-таки класс CActiveRecord предлагает абстракцию только для одной строки в таблице. Кто как выкручивался в такой ситуации?

В родительском контроллере или всё таки в модель кидайте.

А как на счет User::model()->findXXX()? Стандартные методы CActiveRecord помимо абстракции для одной строки, также предосталяют методы для получения списка записей. Поэтому лучше всего методы типа User::getAllActive() располагать в модели. Или можно сделать отдельный класс, например, UserHelper и выносить такие методы туда.

Я подобные методы - размещаю в модели, как и предложил Seb.

Ia etu problemu podnimal dvumia postami ranshe. Rasovo vernoe mesto - sozdaturoven-prosloiku SERVICE.

To est naprimer dla controllera "usersController" dolzen bit klass-servis "usersService" so stati4eskimi metodami.

I togda iz kontrollera nado budet vizivat` usersService::getActiveUsers(), a uze v samom service budet vipolniatsia vsia griaznaia rabota po polu4eniu etix samis activeUsers.

Всем спасибо за ответы=) Подводя итог, могу сказать, что самое идеологически правильное решение предложил товарищ Vlad (несмотря на транслит), но, чтобы не плодить сущности, удобнее наверное размещать такие методы в модели.

Имхо, именно для этого существуют named scopes, в том числе и с параметрами, в CActiveRecord, не знаю, как это корректно звучит по-русски. В definitive guide есть красивый пример типа:

$posts=Post::model()->published()->recently(3)->findAll();

Хотя, конечно, зависит от стандартов кодирования, в действительно больших проектах лучше выносить такие вещи в отдельные классы типа уже названных сервисов или фабрик.

Да, вот только не всегда работа кода заключается в вытягивании чего либо из модели.

Небольшой апдейт - я таки нашел ответ на свой вопрос. Как всегда, надо было всего лишь внимательно прочитать мануал=)

Вся оказалось очень изящно: класс представляет таблицу в базе данных, а экземпляр класса - запись в этой таблице. Таким образом, методы для работы с набором записей идеологически и практически правильно реализовывать в виде статических методов в модели!