Куда должна идти логика генерации отчетов в структуре MVC?

Question

У меня есть проект, который использует настройку Model View Controller.

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

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

С точки зрения хорошей ОО-структуры, где в действительности должен существовать код типа бизнес-логики генерации отчетов?

(Если это поможет сделать ответ более конкретным, это проект php, использующий инфраструктуру CakePHP).

Answer 1

Я могу предложить концептуальный ответ, а также некоторые практические советы.

Вот концептуальный ответ. Представьте, что монитор компьютера и принтер - это две разные машины с одной и той же целью. Их общая задача - отображать или отображать текст и графику. Оба представляют взгляд на модельные объекты. В случае монитора компьютера объекты отображаются на экране. В случае с принтером объекты отображаются на листе бумаги.

Концептуально отчет может быть представлен либо на экране, либо на принтере. Это просто вопрос того, куда направляется информация. Если он направлен на монитор, структура GUI взаимодействует с диспетчером окон ОС для создания представления. Если информация направляется на принтер, генератор отчетов взаимодействует с ОС и драйвером принтера для создания печатной копии.

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

Это концептуальный ответ. На практике я никогда не видел, чтобы это было так. Каждая компания, с которой я работал в течение последних 20 лет, покупает готовый пакет генератора отчетов. Затем они создают класс, такой как ReportGenerator , в своем приложении и используют его как интерфейс для коммерческого программного обеспечения для составления отчетов. Программное обеспечение для отчетов обрабатывает форматирование, а также загрузку и сохранение шаблонов отчетов. Такое программное обеспечение обычно включает в себя хороший графический редактор или создание отчетов. Вы передаете генератору отчетов имя шаблона отчета, данные и принтер. Затем он использует свое волшебство для создания и печати отчета.

Иногда я хочу просматривать отчеты на экране, а не распечатывать их. В этом случае я все еще использую генератор отчетов, но говорю ему создать файл отчета в формате PDF. Затем я использую веб-браузер или Adobe Reader для просмотра отчета на экране.

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

Answer 2

Вы можете рассматривать MVC как базовый шаблон для обработки взаимодействия с пользователем.Это не означает, что вы должны смотреть на все проблемы, которые ваше приложение пытается решить с точки зрения MVC.

Если создание отчета является важной частью, почему бы не иметь что-то вроде ReportGenerator класса?В зависимости от специфики может оказаться полезным создание отчета в качестве отдельного процесса.