控制器逻辑和模板逻辑，与分页的界限在哪里？答案

【问题标题】：Controller logic and template logic, where do you draw the line with pagination?控制器逻辑和模板逻辑，与分页的界限在哪里？
【发布时间】：2010-10-13 22:58:57
【问题描述】：

MVC 框架的全部意义在于将设计（模板）与逻辑（控制器）分开。然而，模板语言通常提供有限程度的“设计逻辑”发生。这包括基本的 if 语句、循环、过滤等。

我创建了一个 Django 模板标签，它可以接受任何列表或 QuerySet 并“分页”它。它根据指定的页面大小将列表拆分为页面，然后将页面添加到上下文中。用法如下：

{% pagify articles by 20 as pages %}

然后我可以调用一个单独的包含来遍历页面，并在我需要的地方生成一个漂亮的页面列表。

这似乎是一种最佳方式，因为它允许我在上下文中对任何列表进行分页；我不必依赖控制器来返回分页结果。但一位同事认为，这对于模板来说似乎过于逻辑。我认为这仍然属于基于设计的逻辑领域，因为即使没有分页，页面仍然可以运行，并且确定页面大小就像是模板的责任。

我的问题是，这个模板的逻辑太多了吗？或者这是一种干净的处理方式？

【问题讨论】：

你的同事听起来很聪明。 :P

标签： django model-view-controller django-templates

【解决方案1】：

我一直认为视图不应该没有逻辑。它只是应该没有任何控制器逻辑。分页只与数据的显示方式有关，这正是视图逻辑应该包含的内容。

【讨论】：

+1。将表示逻辑移动到业务逻辑中只是因为它的逻辑是一件坏事。在某些语言中，您必须这样做，因为模板语言非常弱，但如果您掌握了所有 Python，则无需这样做。
我的问题不在于模板中有 any 逻辑，而在于分页是否被视为模板逻辑或业务逻辑。

【解决方案2】：

这样说；如果您在另一种媒体中使用您的数据模型，例如，不是在 Web 上，而是通过某种基于控制台的应用程序或后台任务，该怎么办？能够通过控制器（或管理器）获取“页面”数据而不是不得不以某种方式依赖模板为您完成这项工作，这不是很好吗？

虽然我当然同意分页数据的“外观”应该由您的模板处理，但分页的“行为”应该留给控制器（Django 视图），甚至通过某种自定义管理器(models.Manager) 方法。

【讨论】：

很好，我没有考虑那么广泛的范围，主要是因为 Django 中的 QuerySets 提供了延迟加载。一旦你开始处理 JSON 数据和其他不呈现模板的视图，我的解决方案就不起作用了。
+1 用于自定义管理器作为分页方式。它不会像我的模板解决方案那样自动化，但它是一种直接处理模型页面的优雅方式。
网站主题/皮肤同样优惠。如果您的客户可以选择他们想要的皮肤，他们可能希望分页对所有皮肤都起作用。我同意，如果它是单行的，那没什么大不了的。但原则上分页不应该过多地依赖演示文稿。

【解决方案3】：

视图不应包含业务逻辑或导航逻辑。您所描述的是表示功能（此处小心避免使用 l 字），可以放置在视图层中。

【讨论】：

【解决方案4】：

您可能想查看django-pagination，它提供了类似的模板标签。

【讨论】：

【解决方案5】：

我同意你的同事的观点；应该为模板提供分页数据，而不是执行分页。我认为，关键问题是确定页面大小是否是模板职责，我不这么认为；我会说它应该在更高的层次上处理。

【讨论】：

好点，我的模板标签确实必须检查对 ?page=1 变量的请求。这就是让它感觉更加以视图为中心的部分。