MVC 框架的全部意义在于将设计（模板）与逻辑（控制器）分开。然而，模板语言通常提供有限程度的“设计逻辑”发生。这包括基本的 if 语句、循环、过滤等。
我创建了一个 Django 模板标签，它可以接受任何列表或 QuerySet 并“分页”它。它根据指定的页面大小将列表拆分为页面，然后将页面添加到上下文中。用法如下：
{% pagify articles by 20 as pages %}
然后我可以调用一个单独的包含来遍历页面，并在我需要的地方生成一个漂亮的页面列表。
这似乎是一种最佳方式，因为它允许我在上下文中对任何列表进行分页；我不必依赖控制器来返回分页结果。但一位同事认为，这对于模板来说似乎过于逻辑。我认为这仍然属于基于设计的逻辑领域，因为即使没有分页，页面仍然可以运行，并且确定页面大小感觉像是模板的责任。
我的问题是，模板的逻辑是否太多？或者这是一种干净的方式来处理这个？
我一直认为，这种观点不应该没有逻辑。它只是应该没有任何控制器逻辑。分页只与数据的显示方式有关，这正是视图逻辑应该包含的内容。
这么说；如果您在另一种媒体中使用您的数据模型，例如，不是在 Web 上，而是通过某种基于控制台的应用程序或后台任务，该怎么办？能够通过控制器（或管理器）获取数据“页面”而不是不得不以某种方式依赖模板为您完成这项工作，这不是很好吗？
虽然我当然同意分页数据的“外观”应该由您的模板处理，但分页的“行为”应该留给控制器（Django 视图）甚至通过某种自定义管理器（models.经理）方法。
视图不应包含业务逻辑或导航逻辑。您所描述的是表示功能（此处小心避免使用 l 字），它可以放置在视图层中。
您可能想查看django-pagination，它提供了类似的模板标签。
我同意你的同事的观点；应该为模板提供分页数据，而不是执行分页。我认为关键问题是确定页面大小是否是模板职责，我不这么认为；我会说它应该在更高的水平上处理。