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 中）视图？

编辑：此常见问题解答条目没有回答我的问题

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 回答