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

これには正解はありません。それは本当にあなたのコーディングスタイルに依存します。検証以外の目的でフォームを使用することは、ビューでこのメソッドを実行するのと同じくらい有効です。

ただし、上記の例にはある種の利点があります。1つのモデルがあり、そのモデルにさまざまなフォーム（さまざまなロジック）を使用したいとします。ビューにロジックを配置して、現在使用されているフォームを確認する代わりに、このロジックをフォームレベルに配置する方がおそらく良いでしょう。

于 2012-06-25T06:21:58.770 に答える
1

この例には何の問題もありません。最も単純な場合を除いて、フォームにはクリーニング方法のみが含まれます。ほとんどのフォームは、追加の検証やその他のアクションを実行します。結局のところ、これは単なるPythonクラスであり、その中で好きなことを行うことができます。多分DRY以外に「ルール」はありません。

外部サービスに対して検証し、他のプロシージャを呼び出し、ワークフローをトリガーするフォームメソッドがあります。このような複雑なロジックの場合、コードの再利用性が向上するため、フォームクラスに埋め込むのが最適です。ビューで作業する開発者は、フォームクラスをライブラリとして使用するだけで、エキゾチックな検証要件について心配する必要はありません。この場合、実際にDRYを促進します。

ロジックを更新する必要がある場合は、フォームクラスの「プライベート」メソッド（プレフィックスが付いているメソッド）のみを更新し_ます。これにより、「パブリック」インターフェース（djangoによって文書化されています）がそのまま維持され、そのフォームを使用するすべてのビューコードを更新する必要がなくなります。

于 2012-06-25T07:33:58.580 に答える
1

同じ奇妙な感覚を初めて感じたのは、LoginFormfromに遭遇したときでした。これは、渡されたクレデンシャルの管理以外に、ユーザーのブラウザーがCookieを操作できるdjango.contrib.authことも確認します。

個人的に、私はあなたに同意します。私は、ビューがフォームではなく電子メールを送信するアクションを実行する責任のあるアクターであり、それ send_emailがビューで定義されたメソッドである必要があると考える傾向があります。

しかし、繰り返しになりますが、私たちの多くがDjangoをどのように異なって使用しているか、または同じ問題を解決するための異なるアプローチを持っているかを簡単に観察できます。アプリケーションを開発する際にさまざまな懸念を念頭に置いているため、特定のフレームワークコンポーネントがどのように使用されるかについて、さまざまな理解を持っている可能性があります。これは少し議論の余地があります。結局のところ、認識しておくべき重要なことは、明確に定義された方法で、ビューからフォームへの重労働の一部を委任することが可能であるということです。

于 2012-06-25T16:10:29.767 に答える