Model view controller MVC结构中的报表生成逻辑应该放在哪里？

我有一个使用模型视图控制器设置的项目

这个项目的一部分是生成一些相当复杂的报告，这些报告需要跨多个模型进行查询

我目前有一个报表控制器，它处理来自用户的请求，并计算出应该呈现哪个报表以及使用哪个参数。。。不幸的是，这个控制器也膨胀到包括所有的报告生成代码。我很确定这段代码在概念上不属于reports controller（它是业务逻辑，而不是路由代码），但它显然也不属于任何特定的模型

就良好的OO设计而言，此报表生成业务逻辑类型代码实际上应该存在于何处

---

（如果有助于使答案更具体，这是一个使用CAKEPHP框架的PHP项目）。

可以考虑MVC作为处理用户交互的核心模式。这并不意味着你应该从MVC的角度来看待你的应用试图解决的所有问题

---

如果报表生成是重要的一部分，为什么不使用类似于

ReportGenerator

类的工具呢？根据具体情况，将报告生成作为一个单独的过程可能会很有用。

我可以提供一个概念性的答案以及一些实用的建议

这是概念上的答案。把计算机显示器和打印机想象成两台用途相同的不同机器。他们的共同任务是显示或渲染文本和图形。两者都将视图显示到模型对象中。对于计算机监视器，对象被渲染到屏幕上。对于打印机，对象渲染在一张纸上

从概念上讲，报告可以呈现到屏幕或打印机。这只是信息指向何处的问题。如果它被定向到监视器，GUI框架将与OS窗口管理器交互以创建视图。如果信息定向到打印机，报表生成器将与操作系统和打印机驱动程序交互以创建硬拷贝

这样的设计可能使用视图类的两个层次结构，使用插入视图类的策略模式，或者设计可能完全是其他的。报表的控制器对象将负责获取和组织要呈现的数据

这是概念上的答案。实际上，我从未见过这样做。我在过去20年中与之合作的每家公司都购买现成的报表生成器软件包。然后，他们在应用程序中创建一个类，如ReportGenerator，并将其用作商业报告软件的接口。报表软件处理报表模板的格式设置、加载和保存。这种软件通常包括一个漂亮的GUI编辑器或设计报告。将报告模板、数据和打印机的名称传递给报告生成器。然后，它运用它的魔力来创建和打印报告

有时我想在屏幕上查看报告，而不是打印报告。在这种情况下，我仍然使用报表生成器，但我告诉它创建报表的PDF文件。然后我使用Web浏览器或Adobe Reader在屏幕上查看报告

---

对于玩具项目或原型以外的任何项目，我建议研究一个旨在生成报告的软件包。说真的。

你把你的报告逻辑放在哪里了？我正在使用CakePHP，也在想同样的事情。也许是一个组件？谢谢