0

django の MVC に問題があります。これが従来の MVC ではないことは理解していますが、ドキュメントでは、実際にプレゼンテーションをビジネス ロジックから分離していることを強調しています。ただし、チュートリアルは次のようなコードになります。

def vote(request, poll_id):
    p = get_object_or_404(Poll, id=poll_id)    

    try:
        selected_choice = p.choice_set.get(id=request.POST['choice'])
    except (KeyError, Choice.DoesNotExist):   
        return render_to_response('polls/detail.html', 
                                  { 'poll': p, 'error_message': 'You didn''t select a choice.' } )
    else:
        selected_choice.votes += 1
        selected_choice.save()
        return HttpResponseRedirect(reverse('mysite.polls.views.results', args=(p.id,)))     

    return render_to_response('polls/vote.html', {'poll': p})

（これは私の実装であるため、チュートリアルとまったく同じではないかもしれませんが、概念は同じです）

この部分で、リクエストを処理し、(場合によっては) データベースにレコードを挿入します。

これは間違っていませんか？モデルのどこかにあるはずではありませんか？より複雑なシナリオではどうなりますか? 多くの db 集中型コードと最小限のプレゼンテーションでビューが乱雑になることはありませんか? 大規模なアプリケーションでは、(LOC のように) ビューがはるかに長くなりますか?

編集:この FAQ エントリは私の質問に答えません

4

2 に答える 2

2

各コンポーネントの目的を誤解しています。Django では、ビューはビジネス ロジック用であり、まさにこの例が示しているものです。表示ロジックはテンプレートに属します。

とはいえ、非常に複雑なモデル固有のロジックがある場合は、モデルにメソッドを記述できますが、もちろんビューから呼び出す必要があります。

いずれにせよ、すべてのデザイン パターンと同様に、MVC はアプリケーションをどのように構築するかの単なるガイドであり、厳格な規則ではありません。

于 2009-12-28T13:05:35.793 に答える
1

石には何も書かれていません。私の考えでは：

  • ビューは、表示されるデータを記述します (これはビジネス固有のものであるため、ビジネス ロジックとしてカウントされますが、ビジネス ルールとしてはカウントされません)。
  • モデルは、データ アクセスとビジネス ルールを記述します (ここに、データに関するドメイン固有のルールのほとんどを集中させます)。
  • テンプレートは、ビューで選択されたデータがフォーマットされる表示レイヤーです。

とはいえ、無駄のないシンプルなテンプレートの哲学が好きだからです。テンプレートの作業をより簡単にするために、データの多くの咀嚼を行うビューが時々あります。私はそれを表示コードとは考えていませんが、そう言っている人が何人かいます。

あなたの例について、あなたは言います：

この部分で、リクエストを処理し、(場合によっては) データベースにレコードを挿入します。

意味がわかりません...

そのビューはモデルを使用して新しいレコードを作成しています。最初に、モデルの更新を要求します。

selected_choice = p.choice_set.get(id=request.POST['choice'])

次に、モデルを変更して保存します。

selected_choice.votes += 1
selected_choice.save()

保存に関するすべてのロジック (オーバーライドされた save() メソッドを含む) はモデルにあります。

モデルのアクションをどこかで処理するコードが必要です。それらはビューです。これらは、表示用のデータの検索を処理し、変更要求の処理を処理します。

于 2009-12-28T14:59:35.033 に答える