DRF 通用视图类 GenericAPIView 让你看看DRF有多方便!
从这篇文章开始,就要讲到DRF的高潮部分,从现在开始,将带你一步一步的,把你原本需要几十、上百行代码解决的问题,一步步简化到只需要4行代码,对你没有听错,4行代码,实现一个通用的RESTful接口的增删改查查!
1. GenericAPIView介绍
GenericAPIView是DRF中的通用视图类,它继承自DRF基础视图类APIView,通用视图类,可以让你只需要配置好类属性,就可以实现一整套的增删查改流程
先来看看我们之前怎么定义一个接口的增删改查
1.1 为什么要使用GenericAPIView
使用APIView实现增删查改Book模型的接口:
# 使用APIView实现
class BookDetailView(APIView):
"""
单个Book查询,Url中传入pk(主键id)
"""
def get(self, request, pk):
book = Book.objects.get(pk=pk) # 用了一次objects.get
serializer = BookSerializer(instance=book)
return Response(serializer.data)
def patch(self, request, pk):
book = Book.objects.get(pk=pk) # 又用了一次objects.get
serializer = BookSerializer(instance=book,data=request.data)
if serializer.is_valid():
serializer.save()
return Response(serializer.data)
else:
return Response(serializer.errors,status=status.HTTP_400_BAD_REQUEST)
def delete(self, request, pk):
Book.objects.get(pk=pk).delete() # 又用了一次objects.get
return Response()
class BookListView(APIView):
"""
书籍列表查询,不传入id,直接创建/查询所有
"""
def get(self, request):
books = Book.objects.all()
serializer = BookSerializer(instance=books,many=True)
return Response(serializer.data)
def post(self, request):
data = request.data
serializer = BookSerializer(data=request.data)
if serializer.is_valid():
serializer.save()
return Response(serializer.data)
else:
return Response(serializer.errors.values(),status=status.HTTP_400_BAD_REQUEST)
我们可以发现什么,发现其实存在着特别多的重复代码
光是objects.get就用 了很多次,而且可以发现,虽然写了书籍查询和多个书籍查询两个类,但是其实就算再去写个作者查询
无非就是把里面的Book变成了Author,里面的BookSerializer变成了AuthorSerializer,所以说,其实不同字段的增删改查,实现的逻辑,代码几乎都是一模一样的,区别就是模型的区别和序列化器的区别。
不同字段实现增删改查的区别:
- 模型的区别
- 序列化器的区别代码
!!逻辑没有区别,就是复制过来改以下模型和序列化器就行!!
所以,DRF提供了通用视图类,可以让我们的代码无用功,大大减少!
2. GenericAPIView重要参数解析
根据我们上面的分析,既然代码实现区别唯一的区别就是模型和序列化器的区别,那么我们就可以把这两个参数,定义成可以随意修改的,然后内部的增删查改逻辑再换着套用,就可以以很少的代码实现多个数据表的增删查改,比如写一个User的增删查改,我们只要把模型和序列化器换成Author,换成Admin,就能用一套代码实现三个表的修改逻辑。
2.1 GenericAPIView的基本使用
下面是使用GenericAPIView的返回多个书籍的视图类,也就是路由中不传入主键的视图
class BookListView(GenericAPIView):
"""
多个书籍的类视图
"""
# 使用GenericAPIView,需要定义两个类属性(名字不能错)
# queryset: 模型类对象的.all()
queryset = Book.objects.all()
# serializer_class: 序列化器类
serializer_class = BookSerializer
# 这就相当于,把上面我们说的模型以及序列化类进行了类级别的定义
# 我们后面的逻辑代码,实现一次,后面再去继承的时候,只需要把类属性改了就行了
def get(self, request):
# self.get_serializer ---> 返回的就是我们类属性中的 serializer_class 的实例化对象
serializer = self.get_serializer(instance=self.get_queryset(), many=True)
# self.self.get_queryset() ---> 返回的就是 类属性中的queryset ---> Book.objects.all()
return Response(serializer.data)
def post(self, request):
serializer = self.get_serializer(data=request.data)
if serializer.is_valid():
serializer.save()
return Response(serializer.data)
else:
return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)
视图中传入主键,返回单个对象/修改单个对象的视图类
class BookDetailView(GenericAPIView):
# 和上面一样的定义方法
queryset = Book.objects.all()
serializer_class = BookSerializer
def get(self, request, pk):
serializer = self.get_serializer(instance=self.get_object())
# get_object就等同于Book.objects.all().filter(pk=pk)
# 相当于帮你完成了查询操作
return Response(serializer.data)
def put(self, request, pk):
serializer = self.get_serializer(instance=self.get_object(), data=request.data)
if serializer.is_valid():
serializer.save()
return Response(serializer.data)
else:
return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)
2.2 GenericAPIView各个参数解析
GenericAPIView其实本质上,就是封装了以下几个重要的参数:
2.2.1 self.get_queryset()
这个其实本质上就是返回我们定义的类属性中的queryset
class BookDetailView(GenericAPIView):
queryset = Book.objects.all() # 这里定义的queryset就是后面的self.queryset
serializer_class = BookSerializer
......
2.2.2 self.get_serializer
这个其实本质上也是我们定义的类属性中的serializer
get_serializer源码
def get_serializer(self, *args, **kwargs):
"""
Return the serializer instance that should be used for validating and
deserializing input, and for serializing output.
翻译:返回用于序列化/反序列化的序列化器
"""
serializer_class = self.get_serializer_class() # 就是我们类定义的serializer_class
kwargs.setdefault('context', self.get_serializer_context())
return serializer_class(*args, **kwargs) # 最后把我们传入的参数又传入进了serializer_class()
2.2.3 self.get_object (重点)
其实就相当于把我们定义的queryset又帮我们进行了查询
之前基于APIView的实现方式
def get(self, request, pk):
book = Book.objects.get(pk=pk)
# 现在的self.get_object就相当于帮我们返回了一个之前的这样的book
serializer = BookSerializer(instance=book)
return Response(serializer.data)
新方式的实现
def get(self, request, pk):
serializer = BookSerializer(instance=self.get_object())
return Response(serializer.data)
2.2.4 self.get_object的坑!!
使用self.get_object的时候,必须传入参数pk,并且必须使用有名路由进行映射!!
urls.py
path("book/<int:pk>/", BookDetailView.as_view()) # 正确的路由方式1,并且必须命名为pk
re_path("book/(?P<pk>\d+)/",BookDetailView.as_view()) # 正则路由|正确的路由方式2,并且必须命名pk
re_path("book/(?P<id>\d+)/",BookDetailView.as_view()) # 错误路由方式,没有命名为pk
re_path("book/(\d+)/",BookDetailView.as_view()) # 错误路由方式,不能使用位置参数去传参!!!
为什么要这样做?我们来看看self.get_object的源码
self.get_object源码
所以要不就乖乖听话传pk,要不就把lookup_field给改了
如果要修改就这样写
class BookDetailView(GenericAPIView):
queryset = Book.objects.all()
serializer_class = BookSerializer
lookup_field = 'id'
# 这就相当于在创建视图类的时候就覆盖原本的pk
# 但是你路由也必须改成传id参数
3. GenericAPIView到底牛在哪里?
在上面,我们已经实现了增删改查查的各种逻辑,说白了区别就在于类定义的时候设施的两个参数
所以,我们后面如果对其他的类还是需要实现类似的操作,可以直接继承已经实现好的Book类
简单来讲,Book类现在已经能直接增删改查了,现在作者Author字段,也需要实现这样的,那直接改两个参数不就完事儿了??
Author的实现:
class AuthorListView(BookListView):
# 直接继承BookListView,然后改下面两个值
queryset = Author.objects.all()
serializer_class = AuthorSerializer
class AuthorDetailView(BookDetailView):
# 直接继承BookDetailView,然后改下面两个值
queryset = Author.objects.all()
serializer_class = AuthorSerializer
然后把路由再一改,这不直接完事儿了??
上面写的那么多代码,后面你如果要用,直接继承就完事儿!!
现在假设我还有Admin,还有牛羊狗鸡,我直接继承不就完事儿??
class DogListView(BookListView):
# 定义Dog的model类
# 定义Dog的序列化器
class DogDetailView(BookListView):
# 定义Dog的model类
# 定义Dog的序列化器
————————Dog的增删查改完事儿了——————————
然后下面不管你是牛马蛇神,咔咔一顿继承就完事儿!!
4. 还有更牛的!!!
看了上面的,你可能已经觉得很牛逼了,但是DRF,其实把这些全部都封装好了,你连增删查改都不用写,他提供了Mixin机制,直接帮你完成增删查改,post,get你都不用定义,直接写个model,再写个序列化器就完事儿!
class DogDetailView(BookListView):
# 定义Dog的model类
# 定义Dog的序列化器
————————Dog的增删查改完事儿了——————————
然后下面不管你是牛马蛇神,咔咔一顿继承就完事儿!!
# 4. 还有更牛的!!!
**看了上面的,你可能已经觉得很牛逼了,但是DRF,其实把这些全部都封装好了,你连增删查改都不用写,他提供了Mixin机制,直接帮你完成增删查改,post,get你都不用定义,直接写个model,再写个序列化器就完事儿!**
**后续文章会继续讲解DRF有多方便!!**