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})

（这可能与教程中的完全不同，因为它是我的实现，但概念是相同的）

在此部分，它处理请求，并（可能）将记录插入数据库。

这不是错的吗？它不应该在模型的某个地方吗？更复杂的情况会发生什么？这些视图是否会被大量的数据库密集型代码和最少的表示混乱？较大的应用程序有更长的时间（如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（）方法）都在模型中。

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

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

2 个答案: