используй ORM. оно прекрасно на концепцию MVC ложится.

ИМХО

Делаешь несколько моделей (для поиска, для вывода свежего, для вывода страницы деятеля и т.д.). Задача контроллера вызвать правильную модель и представление (хотя представление может быть у них одинаковое - список песен, например)

Закидывай SQL и прочее внутрь модели, а из контроллера дёргай методы модели. По сути получится такой мини-ORM, который можно развивать в зависимости от задачи. А для параметров придумай какой-нить способ, тут главное универсальнее сделать, чтобы потом переделывать не надо было.

> Делаешь несколько моделей (для поиска, для вывода свежего, для вывода страницы деятеля и т.д.)

зачем такой overhead? это все можно сделать методами в модели.

>А для параметров придумай какой-нить способ, тут главное универсальнее сделать, чтобы потом переделывать не надо было.
Дык, речь как раз о том, как придумать способ поуниверсальнее, не превращая его в собственно SQL или его подобие)
Можно, конечно, сразу ограничиться запросами, необходимость поддержки которых можно предположить на данном этапе, реализовав их методами модели, как предлагает isden, но тогда при необходимости что-то дописать нужно будет лезть и в контроллер, и в модель.

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

Можно, конечно, сразу ограничиться запросами, необходимость поддержки которых можно предположить на данном этапе, реализовав их методами модели, как предлагает isden, но тогда при необходимости что-то дописать нужно будет лезть и в контроллер, и в модель.

Сделай, например, универсальный метод на модели «search», принимающий толстый массив, в нём передавай, например, пары «поле-значение», в модели просто парси его и превращай в зависимости от необходимости в SQL, поиск по файлам итд. Чтобы что-то дописать, надо будет добавить код в модель, а в контроллере практически ничего менять не нужно будет.

Сделай вообще вызовы разных типов через взаимозаменяемые бэкенды. Посмотри, например, на исходники какого-нибудь ORM - они там обычно долго думают о том, как всё сделать, у них интересные решения.

> но тогда при необходимости что-то дописать нужно будет лезть и в контроллер, и в модель.

а универсальных решений и не существует. код нужно писать с оглядкой на наиболее эффективную реализацию того что нужно и, желательно, с возможностью дальнейшего расширения (впрочем, это скорее задача планирования архитектуры а не реализации).
при добавлении, например, доп. поля в объект модели, тебе,скорее всего, полюбому придется лезть во все три части Model-View-Controller.
ORM же поможет тебе тем, что у тебя будет некое стандартное внутреннее представление/API через методы модели, независимое от того MySQL юзается или же plain-text.

типа такого:
1. модель - просто класс, содержащий набор private-свойств и паблик-методов для доступа к ним (setЧто-то-там(value) и getЧто-то-там()). Будет использоваться как тип данных в программе для всяческих манипуляций;
2. маппер - класс, непосредственно связывающий модель с хранилищем, там будут методы типа save(Model), delete(Model), find(id) и т.д;
3. набор объектов бизнес-логики, которые инкапсулируют внутри себя работу с моделями и мапперами и предоставляют более обобощенный интерфейс. один объект бизнес-логики может запросто работать внутри себя с несколькими моделями сразу;

вот уже с элементами бизнес-логики и будет работать контроллер.