django过滤器的作用。在视图中过滤或预先格式化？

我想听听你对此的看法

我有一个django应用程序，其中从模型中获得的数据是粗略的。为了使它们更好，我必须做一些可能很复杂但不多的操作。 例如，假设您有一个模型，其中美国州被编码为两个字母的代码。在html呈现中，您希望向用户显示完整的状态名称。我在另一个db表中有两个字母->全名的对应关系。假设我不想执行连接

我有两个选择

让视图代码从模型中提取两个字母的信息，然后对第二个表执行查询，获取全名，并将其放入上下文中。模板呈现完整的状态名称

创建一个自定义筛选器，该筛选器接受两个字母代码，命中db并返回完整的名称。让视图将两个字母的信息传递到上下文中，并将管道放入模板中的过滤器中。过滤器将两个字母的代码呈现为完整字符串

现在，这些解决方案似乎是等效的，但从设计的角度来看，它们不可能是等效的。我有点怀疑过滤器责任和视图责任之间的界限在哪里。解决方案1执行解决方案2中的过滤器任务，它只是集成在视图本身中。当然，如果我必须在同一页面内多次调用过滤器，那么解决方案1可能会更快（除非过滤器输出被记忆）

---

您对设计、正确编码和性能有何看法？

在我看来，您的模型应该有一种转换方法。制作一个过滤器似乎需要额外的工作，我不认为大多数Django开发人员会在过滤器中期望这样的事情

---

过滤器应该更通用—格式化和显示数据，而不是查找。

我的观点是，从设计角度来看，第一个解决方案要干净得多。我希望将模板层看作是演示的最后一个阶段，在这个阶段中，所有信息都由视图传递（以最终形式）

最好将所有的“计算逻辑”都放在视图中。那样的话：

• 阅读和理解要容易得多（特别是对于第三方）

• 如果您需要更改某些内容，您可以专注于特定的视图方法，并确保需要更改的所有内容都在其中（无需从视图切换到模板）

至于表现，我认为你的观点是正确的。如果要多次执行相同的查找，则第二种解决方案更糟糕

编辑：

---

提到ashchristopher的评论，我实际上是想说它肯定不属于模板。什么是业务逻辑以及“数据提供”和“业务逻辑”之间的界限究竟在哪里永远都不清楚。在这种情况下，阿什克里斯托弗似乎是对的。将状态代码转换为完整的状态名称可能是一个与数据库相关的编码问题，而不是一个业务逻辑问题。

虽然我同意，但在这两个解决方案中，第一个更好。。。我仍然认为这种模式是属于它的。该模型不仅仅是数据库的接口。它应该用来收集和处理数据。该视图用于执行业务逻辑，而将alpha-2国家代码转换为全名几乎不是业务逻辑。。。这是数据操纵。