【问题标题】:Django views, logic, and skinny controllersDjango 视图、逻辑和瘦控制器
【发布时间】:2013-04-23 12:53:51
【问题描述】:

所以,我有一个基于 django.views.generic.View 的 Django 视图,它只接受 POST 请求。它接受application/x-www-form-urlencoded 格式的基本调用,解析它们,然后做出适当的响应。我意识到这在瘦控制器、胖模型的想法上失败了,但我不确定放置以下逻辑的最佳位置,因为它与视图相关,而不是专门与底层模型相关。

目前,视图处理一些创建新订阅的逻辑:

class ExampleView(View):

   def post(self, request, *args, **kwargs):
        mode = request.POST.get('mode')

        if not mode:
            return HttpResponse('mode required', status=400)

        if mode == 'subscribe':
            if not request.POST.get('topic'):
                return HttpResponse('topic required', status=400)

            if not [ another required argument ]:
                and so on ...

            [ If we're ready to roll, create a Subscription object ]

            return HttpResponse('Subscribed', status=200)

所以,在我看来,这就像将逻辑放在错误的层中一样。哪里是处理传递给视图的最佳位置,以及生成/失败生成订阅对象的最佳位置。

是否应该在 Subscription 对象上处理提供的数据,然后将 HttpResponses 返回给视图?还是应该只返回状态和消息,然后由创建正确 HttpResponse 对象的视图转发给用户?

【问题讨论】:

  • 听起来您可能可以使用ModelForm 来进行验证,但这可能有点矫枉过正。关于放置此类代码的最佳位置是有争议的,因此任何答案都可能与任何其他答案一样有效。

标签: python django django-models django-views


【解决方案1】:

处理传递给视图的内容的最佳位置,以及 根据需要生成/无法生成订阅对象

是观点,我想。所以,我认为您提供的代码 sn-p 是绝对正确的。

部分数据验证逻辑可以封装在表单中:

    if form.is_valid():
        [ we're ready to roll, create a Subscription object ]
    else:
        return HttpResponse('%...' % form.errors, status=400)

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2011-08-24
    • 2012-01-25
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-09-17
    相关资源
    最近更新 更多