在视图中处理请求/访问数据库是一种好习惯吗？

Question

我对 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 中）？

编辑：This FAQ entry doesn't answer my question

Answer 1

您误解了每个组件的用途。在 Django 中，视图用于业务逻辑，这正是示例所演示的。显示逻辑属于模板。

也就是说，如果您有非常复杂的特定于模型的逻辑，您当然可以在模型上编写一个方法 - 当然，您仍然需要从视图中调用它。

在任何情况下，与所有设计模式一样，MVC 只是指导您如何构建应用程序的指南，而不是一成不变的规则。

Answer 2

没有什么是一成不变的。在我看来：

• 视图描述了要呈现的数据（这是特定于业务的，因此它算作业务逻辑，而不是业务规则）
• 模型描述数据访问和业务规则（这是我集中关于我的数据的大部分领域特定规则的地方）
• 模板是显示层，其中视图中选择的数据被格式化。

那是因为我更喜欢精益、简单模板的理念；有时我会看到视图对数据进行大量的记忆，以使模板的工作更简单。我不认为这是显示代码，但有人告诉我它是。

关于你的例子，你说：

在这部分，它处理请求，并且（可能）将一条记录插入到数据库中。

我不明白你的意思...

该视图正在使用模型创建新记录。首先它要求模型更新：

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

然后修改模型并保存：

selected_choice.votes += 1
selected_choice.save()

所有关于保存的逻辑（包括任何覆盖的 save() 方法）都在模型中。

您必须有代码在某处处理模型上的操作。这些是意见。它们处理查找数据以进行显示，并处理处理修改请求。