Автор оригинала: Screjet
1. Бизнес-логига (выборка данных, выполнение операций с данными, вычичсления, и т.д.)
Стандартная практика. п.1 = это модель.
Сейчас все популярнее становится схема, когда представление (особенно реализация с активными шаблонами) работает вообще в обход модели по примерно такой схеме:
БД <= DAO <= Helper <= View
DAO может отсутствовать, тогда запросы выполняются непосредственно в Helper. Такой подход может привести к дублированию кода в доменных классах и в хелпере (например если не использовать DAO специфические преобразования полей приходится делать и там и там), однако является очень гибким.
Представьте, что необходимо сделать выборку из 5 таблиц, каждая из которых представлена в домене отдельным классом. Реализуем либо в DAO либо в хелпере метод, выполняющий нужный запрос, и возвращающий в общем случае Record Set или проще говоря массив строк таблицы, которые готовы для использования в шаблоне. И никаких манипуляций с объектами, никаких объектов модели в шаблонах. Все просто и красиво.
-~{}~ 17.05.05 19:35:
Автор оригинала: Domovoj
2. Логика отображения (подготовка имён CSS классов, создание массивов на основе настроек магазина (это про кол-во столбцов), и т.д.)
3. Файлы-шаблоны, просто отображающие (с минимальным кол-вом IF и FOREACH) данные, подготовленные в 2.
В принципе это и есть описываемая схема с хелпер объектами. В случае с активным шаблоном, шаблон запрашивает у хелпера нужные данные, например "дай мне список пользователей, с автаром, количеством постов, и количеством штрафных очков", а хелпер возвращает ему данные в обычной структуре. И шаблону (представлению) не нужно знать, что на самом деле выборка была произведена из 4 таблиц, он лишь знает, какие поля может использовать при отображении.