3

当我在基于类的视图上研究新的 django 文档时，我注意到这个示例代码：

# forms.py
from django import forms

class ContactForm(forms.Form):
    name = forms.CharField()
    message = forms.CharField(widget=forms.Textarea)

    def send_email(self):
        # send email using the self.cleaned_data dictionary
        pass

将观看send_email视为一种方法的事实ContactForm真的让我很恼火。我一直认为表单方法应该用于验证目的，而使用表单的方法（如send_email本例中）应该在视图层中。我在这里错过了什么吗？还是应该纠正这个例子？

4

3 回答 3

4

这个没有正确答案。这真的取决于你的编码风格。使用表单进行的不仅仅是验证与在视图中执行此方法一样有效。

上面的例子虽然有某种优势。假设您有一个模型，并且您想为它使用不同的形式（具有不同的逻辑）。与其将逻辑放在视图中并检查现在使用哪个表单，不如将此逻辑放在表单级别上。

于 2012-06-25T06:21:58.770 回答
1

我第一次有同样奇怪的感觉是当我遇到LoginFormfrom时django.contrib.auth，它还验证了用户的浏览器除了管理传入的凭据之外还能够使用 cookie 。

就个人而言，我同意你的看法。我更倾向于认为视图应该是负责执行发送电子邮件而不是表单的操作的参与者，这 send_email应该是视图中定义的方法。

但是，话又说回来，你可以很容易地观察到我们很多人如何以不同的方式使用 Django，或者有不同的方法来解决相同的问题。由于在开发应用程序时我们有不同的考虑，我们很可能对某些框架组件的使用方式有不同的理解，这有点争议。最后，重要的是要承认，可以以明确定义的方式将视图中的一些繁重的工作委派给表单。

于 2012-06-25T16:10:29.767 回答
1

这个例子没有错。除了最简单的情况外，您的表格将只包含清洁方法；大多数表单都会进行额外的验证和其他操作。最后，它只是一个 Python 类，你可以在其中做任何你想做的事情；除了 DRY 之外，没有“规则”。

我们有针对外部服务进行验证、调用其他程序和触发工作流的表单方法。对于如此复杂的逻辑，最好将其嵌入到表单类中，这样可以增加代码的可重用性。开发视图的开发人员只需将表单类用作库，而不必担心奇异的验证要求。在这种情况下，它实际上促进了 DRY。

当我们必须更新逻辑时，我们只更新表单类的“私有”方法（那些以 为前缀的_）。这使“公共”界面（由 django 记录）保持完整，并且不必更新使用该表单的所有视图代码。

于 2012-06-25T07:33:58.580 回答