Допустим у меня есть некий модуль, который использует этот класс.
В свою очередь этот модуль содежрит код логики рендеринга пейджера(у меня он аля google), но самого дизайна там нету. Он работает с шаблонами(в моем случае это HTML-шаблоны).
Что мы имеем? А имеем мы трехзвенку.
1 уровень данных(это собственно класс), на этом уровне ничего не известно не о выводе данных, ни о логике вывода, код занимается только самими данными(этот пример не очень удачный, обычно такие классы у меня инкапсулируют еще и всю работу с бд).
2 уровень логики представления, на этом уровне мы реализуем всю логику работы нашего пейджера, и обственно вывод.
3 уровень представления, здесь у нас будет просто html-шаблон, котоырй при желании легко меняется на xml/xslt, например. При этом нужно будет сделать минимальные изменения на втором уровне, а первого уровня это вообще никак не коснется.
Ну вот примерно так.
У меня есть класс новостей(публикаций). Работает по той же системе.
Есть разные представляения новостей: html, xml(rss), текстовый файл и вообще может быть, что угодно, но при этом я уже не затрагиваю сам класс новостей, я лишь создаю экземпляр и вызываю нужный метод, в ответ получаю данные, которые мне нужны.
Такая архитектура полностью оправдала себя за год интенсивного использования в различных проектах.
И это не CMS. Т.к. я заранее не делаю представление. У меня есть набор классов, есть административный интерфейс, есть несколько типовых модулей.
Создание нового сайта начинается с того, что я делаю новые шаблоны и создаю новые модули представления, при этом почти никогда не меняя сами классы.
p.s. замечу, что я работаю с очень старой версией mysql 3.23.58, а так можно было бы переложить значительную часть логики работы с данными на плечи СУБД.