我有一个使用模型视图控制器设置的项目。
该项目的一部分是生成一些需要跨多个模型查询的相当复杂的报告。
我目前有一个报告控制器，它处理来自用户的请求并确定它应该呈现哪个报告以及使用哪些参数......不幸的是，这个控制器也膨胀到包括所有报告生成代码。我很确定这段代码在概念上不属于报告控制器（它是业务逻辑，而不是路由代码），但它显然也不属于任何特定模型。
就良好的 OO 设计而言，这种报表生成业务逻辑类型的代码实际上应该放在哪里？
（如果它有助于使答案更具体，这是一个使用 CakePHP 框架的 php 项目）。
【问题讨论】：
您可以将 MVC 视为处理用户交互的核心模式。这并不意味着您应该从 MVC 的角度查看您的应用程序试图解决的所有问题。
如果报告生成是重要的部分，为什么不使用类似ReportGenerator 的类？根据具体情况，将报告生成作为一个单独的过程甚至可能很有用。
【讨论】：
我可以提供一个概念性的答案以及一些实用的建议。
这是概念性的答案。将计算机显示器和打印机视为具有相同用途的两台不同机器。它们的共同任务是显示或渲染文本和图形。两者都呈现模型对象的视图。在计算机监视器的情况下，对象被渲染到屏幕上。在打印机的情况下，对象被渲染在一张纸上。
从概念上讲，报表可以呈现到屏幕或打印机。这只是信息指向何处的问题。如果它被定向到监视器，则 GUI 框架与 OS 窗口管理器交互以创建视图。如果信息被定向到打印机，则报告生成器与操作系统和打印机驱动程序交互以创建硬拷贝。
这样的设计可能会使用视图类的两个层次结构，使用插入到视图类中的策略模式，或者设计可能完全不同。报告的控制器对象将负责获取和组织要呈现的数据。
这是概念上的答案。在实践中，我从未见过这样做过。在过去的 20 年中，我合作过的每家公司都会购买现成的报告生成器包。然后他们在他们的应用程序中创建一个类似 ReportGenerator 的类，并将其用作商业报告软件的接口。报告软件处理报告模板的格式化以及加载和保存。此类软件通常包括一个不错的 GUI 编辑器或设计报告。您将报告模板的名称、数据和打印机传递给报告生成器。然后它会发挥它的魔力来创建和打印报告。
有时我想在屏幕上查看报告而不是打印它们。在这种情况下，我仍然使用报告生成器，但我告诉它创建报告的 PDF 文件。然后我使用 Web 浏览器或 Adobe Reader 在屏幕上查看报告。
对于玩具项目或原型以外的任何东西，我建议您研究一个旨在生成报告的软件包。认真的。
【讨论】：