构建日历时如何分离逻辑和表示代码？

Posted 2023-05-08

【中文标题】构建日历时如何分离逻辑和表示代码？

【英文标题】：How can I separate logic and presentation code when building a calendar?

【发布时间】：2011-08-11 11:30:46

【问题描述】：

好的，我们有一个页面。一个非常简单的。我们称之为page.php。它将有一个控制器和一个视图。控制器将捕获一些 GET 变量并将它们打印在该页面的开头，视图将显示一个页眉、页脚和一个包含来自控制器的 GET 变量的段落。

现在让我们假设我们想要添加一个日历。你认为这很好，很容易。嗯，对我来说根本不是。

日历由纯 html 的 <table><tbody>X</tbody></table> 和一个逻辑 PHP 脚本（将填充 X）组成，该脚本将创建（基于当前日期和时间的 time()stamp）月份日期和数字。

现在我遇到了一个道德问题：我如何划分日历的逻辑和视图？

将创建日期的代码块将打印<td> 和<tr> 详细说明time()。但是如果逻辑打印 HTML 是不是很糟糕？我认为是这样，因为您放弃了 MVC 模式典型的称为“逻辑和视图的划分”的舒适想法。

同时，如果我们将所有日历逻辑发送到控制器，我们只需发送到视图和日期数组（用坐标 X 和 Y 告诉他将月份的第一个日期放在哪里）视图仍然需要详细说明数组，并且也将成为逻辑。

我如何才能真正从这个日历中划分逻辑和视图？

【参考方案1】：

在视图中简单地迭代数组是完全可以的，并且不违反 MVC 模式。逻辑发生在您填充数组的控制器中。更好的方法可能是将逻辑放入名为 Calendar.php 的模型中，然后在控制器中简单地对其进行初始化以将其传递给视图。

【参考方案2】：

你可以将逻辑代码放在一个php文件中，并将结果分配给将在视图文件中显示的变量（例如数组）

在视图文件中，您可以轻松地回显变量并放置 html 标签。

【讨论】：

为什么这是最好的建议？这听起来像是一个完全随机的建议。为什么是 ZF 而不是其他框架？为什么要使用框架？

您可以搜索采埃孚的好处，如果您使用采埃孚，您可以轻松管理视图、控制、模型。 ZF 依赖于 MVC 结构。您可以使用许多库。一开始需要一些时间来学习，但之后你可以在更短的时间内开发你的项目

而我只能用 ZF 做到这一点？不是也有其他框架，比如 Symfony？还是 Zeta 组件？或者甚至根本没有框架？这不像 MVC 是火箭科学。就像我说的，你的建议似乎完全是随机的。

好的，戈登。我编辑了那个。你不能使用 ZF ，永远不要使用 :P :D