django休息框架是什么意味着视图与视图之间的折衷？ [英] What does django rest framework mean trade offs between view vs viewsets?

问题描述

我不知道为什么文档说这并不意味着它总是正确的方法。在使用基于类的视图而不是基于函数的视图时，需要考虑一组类似的权衡。不如单独建立你的观点。

如果我想休息api，这类似于ruby-on-rail。我认为 viewsets 是一个很好的方法。

任何人可以解释更多关于它吗？

文档链接：
http://www.django-rest-framework.org/tutorial/6-viewsets-and-routers/#trade-offs-between-views-vs-viewsets

解决方案

使用 viewsets 超过视图简洁。在简单的情况下，您可以使用较少的代码行完成更多操作。

主要缺点是由 viewsets 可能并不总是适合您正在工作的问题空间。与Django中基于类的视图一样，如果您尝试将错误的模式应用于问题，您可以最终做更多的工作，而不需要解决问题。

我的个人启发式是，如果我在一个模型上完成一整套CRUD操作，我从$ code> viewsets开始从那里开始，直到我觉得他们提供的便利不再值得我在这个具体情况下产生的麻烦;如果我正在使用API​​映射到任何型号的API端点，我更有可能使用视图。

编辑：

为了回应您的评论，这里是一个代码示例。如果我有以下型号：

models.py

 $ d $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ 
 $ G $ $ $ $ $ $ $ $ $ $ $ b b b b b b b b b b b b b b b b b b b b b b b b b last_dusted = models.DateField（null = True）
 
 class Sprocket（models.Model）：
 nom = models.CharField（blank = True，null = False）
 last_dusted = models.DateField（null = True）
  

我想支持标准HTTP方法的正常含义（即列表视图中的GET和POST以及详细视图中的GET，PUT和DELETE），我将创建一个 GizmoViewSet ，一个 SprocketViewSet 并称之为一天。

说我也想让API消费者能够一次性清除所有的小玩意儿。在这种情况下，将 dust 方法添加到 GizmoViewSet 中使用 @ list_route 装饰器。假设我真正想要做的是提供一个端点，其API消费者可以将所有的 Gizmo 和 Sprocket 一次关闭。这不是很好地映射到任何一个viewset，所以我添加一个视图：

  import datetime 
 
 from rest_framework.decorators import api_view 
 from rest_framework.response import Response 
 
 from my_app.models import Gizmo，Sprocket 
 
＃我用了基于功能的API视图，但CBV APIView 
＃也可以正常工作。个人喜好的事情
 @api_view 
 def dust_everything（request）：
 today = datetime.date.today（）
 Gizmo.objects.all（）。update last_dusted = today）
 Sprocket.objects.all（）。update（last_dusted = today）
返回响应（{status_of_dusting：success}）
 所以在这种情况下，我不会把我的所有观点都删掉，而是用意见来代替它们。我添加了一个额外的视图来补充现有的视图，这是有意义的。
 
I don't know why document said "That doesn't mean it's always the right approach to take. There's a similar set of trade-offs to consider as when using class-based views instead of function based views. Using viewsets is less explicit than building your views individually."

If I want to make rest api, which is similar to ruby-on-rail. I think viewsets is a good approach to take.

Can Anyone explain more about it?

Document link:
http://www.django-rest-framework.org/tutorial/6-viewsets-and-routers/#trade-offs-between-views-vs-viewsets
解决方案
The main advantage of using viewsets over views is brevity. In the simple case you can get more done with fewer lines of code.

The main disadvantage is that the simplifying assumptions made by viewsets might not always fit the problem space you are working in. As with class-based views in Django, if you try to apply the wrong pattern to a problem you can end up doing more work than you need to to solve a problem.

My personal heuristic is that if I am doing the full set of CRUD operations on a model, I start with viewsets and go from there until I feel the convenience they provide is no longer worth the trouble I am incurring in that specific instance; if I am working with an API endpoint that doesn't map to any models, I'm far more likely to just use a view.

Edit:

In response to your comment, here's an example in code. If I had the following models:

models.py
from django.db import models

class Gizmo(models.Model):
    name = models.CharField(blank=True, null=False)
    last_dusted = models.DateField(null=True)

class Sprocket(models.Model):
    nom = models.CharField(blank=True, null=False)
    last_dusted = models.DateField(null=True)
And I wanted to support the standard HTTP methods with their normal meanings, (namely GET and POST on the list view and GET, PUT, and DELETE on the detail view), I'd create a GizmoViewSet, a SprocketViewSet and call it a day.

Say I also wanted to offer API consumers the ability to dust off all of the gizmos at once. In that case it would make sense to add a dust method to the GizmoViewSet using the @list_route decorator. Suppose that what I really wanted to do though was to offer a single endpoint where that API consumer could dust all the Gizmos and the Sprockets off at once. That doesn't really map very well to either viewset, so I'd add a one off view:
import datetime

from rest_framework.decorators import api_view
from rest_framework.response import Response

from my_app.models import Gizmo, Sprocket

# I used a function-based API view here, but a CBV APIView
# would work just as well. Matter of personal preference...
@api_view
def dust_everything(request):
    today = datetime.date.today()
    Gizmo.objects.all().update(last_dusted=today)
    Sprocket.objects.all().update(last_dusted=today)
    return Response({"status_of_dusting": "successful"})
So in that case I wouldn't be tearing out all my viewsets and replacing them with views; I'm adding an extra view to supplement the existing viewsets where it makes sense.

                        
这篇关于django休息框架是什么意味着视图与视图之间的折衷？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！