报告生成逻辑应该放在MVC结构中何处？

Question

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

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

我目前有一个报告控制器，它处理来自用户的请求，并计算出它应该渲染哪个报告以及哪些参数......不幸的是，这个控制器也膨胀以包含所有的报告生成代码。我很肯定这个代码在概念上并不属于报表控制器（它是业务逻辑，不是路由代码），但它也明显不属于任何特定的模型。

在良好的面向对象设计方面，这个报表生成业务逻辑类型代码应该在哪里居住？

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

Answer 1

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

如果报告生成是重要的部分，为什么不能有类似ReportGenerator类？根据具体情况，将报告生成作为一个单独的过程甚至可能是有用的。

Answer 2

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

这里是概念答案。将计算机显示器和打印机视为具有相同用途的两台不同机器。他们的共同任务是显示或呈现文本和图形。两者都提供了模型对象的视图。在计算机监视器的情况下，对象呈现为屏幕。在打印机的情况下，对象被渲染在一张纸上。

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

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

这是概念上的答案。在实践中，我从来没有见过这样做。在过去的20年中，每个与我合作过的公司都购买了现成的报告生成器软件包。然后，他们在其应用程序中创建类似ReportGenerator的类，并将其用作商业报告软件的界面。报告软件处理报告模板的格式和加载以及保存。这样的软件通常包含一个不错的GUI编辑器或设计报告。您将报告生成器传递报告模板的名称，数据和打印机。然后它创建并打印报告就会发挥它的魔力。

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

对于玩具项目或原型以外的任何东西，我建议您查看一个软件包，其目的是生成报告。认真。