欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

drf

程序员文章站 2022-07-12 11:12:36
...

APIView
APIView是drf概念体系中最基本类视图,它基于Django的View,同时又实现了一层对自己创造的概念的封装,比如permission_classes,render_classes,authentication_classes等,相当于请求过来后又进入一层,过滤(验证、初始化)完要走的这些classes,才能执行到我们自己实现的view。

Mixin
在介绍Generic view前先说一下mixin。说白了,官方给的案例里面的mixin,就是对model的object增删改查的原子操作。比如RetrieveModelMixin,通过get_object先获取到对象,然后通过serializer拿到序列化数据。

class RetrieveModelMixin(object):
    """
    Retrieve a model instance.
    """
    def retrieve(self, request, *args, **kwargs):
        instance = self.get_object()
        serializer = self.get_serializer(instance)
        return Response(serializer.data)

延伸开来,Mixin是一个非常重要的概念,因为它是模块化拆分后最关键的原子逻辑实现,是每一个单独的块。试想下,我们可以通过这些小块拼接成不同的功能,比如用户注册功能,使用者有可能在手机注册,有可能在web注册,在Django后端中可能需要提供两套view层接口,甚至还有渲染template的实现,但是真正的逻辑处理上,可以只调用一个RegistMixin的东西,从而提高代码复用,降低维护成本。

甚至,Mixin可以重写同时继承的GenericAPIView中的实现,比如request参数处理,Response数据处理(视频、文件格式之类),get_queryset,get_serializer等等有通用需求,并且会在多个地方复用的定制,比如根据传入参数指定需要的serializer从而在mixin中重写get_serializer方法的实现逻辑。总之,原本会在View中发生的一切,都可以通过Mixin封装起来,或重写、或新的逻辑实现。

Generic views
典型的Generic view就是这样的,本质上是类视图,它由一些Mixin组成,这里的ListModelMixin实现了list()方法,并同时继承自GenericAPIView,同时自己实现了由get()到list()的转发。复杂的是,GenericAPIView实现,以及他的执行过程,和后期对里面函数的重写、定制。所以抽时间多研究下这里很值得,以后也会节省大量时间。

class ListAPIView(mixins.ListModelMixin,
                  GenericAPIView):
    """
    Concrete view for listing a queryset.
    """
    def get(self, request, *args, **kwargs):
        return self.list(request, *args, **kwargs)

如果要实现的逻辑不是很复杂的话,直接在view中继承一个[List[Create[Update]]]APIView,然后指定下serializer_class,permission_class,queryset等就可以了。对drf熟悉的话相信这种方式实现功能会很快。

Viewsets
先看代码,ViewSet继承了ViewSetMixin和APIView,ViewSetMix是APIView中as_view的重写,实现请求到action的转发,虽然Django自带的View也实现了as_view,但只是传递初始化参数,确实没有这个请求转发到action的实现,APIView里面也没有。这里也可以学习到:Python的多重继承中,子类形参的先后顺序,影响到执行的是哪个类中的as_view方法,相当于ViewSetMixin又继承了APIView。

class ViewSet(ViewSetMixin, views.APIView):
    """
    The base ViewSet class does not provide any actions by default.
    """
    pass

viewsets和APIView不一样的地方在于,它要表达的更多的是一个方法视图的集合,他的内部是已经实现了的list(),retrieve(),delete(),update()的实现,如果实现用drf的DefaultRouter。router和as_view都可以实现GET请求–>list()的转发,值得一提的还有detail_route和list_route(最新版本推荐使用action),他们需要在urls中配置router的前提下使用,在Router类的get_url里面的get_routers执行,然后获得所有的路由列表,再进行action转发。

# account/views.py
class AccountViewSet(viewsets.ModelViewSet):
    """
    对Account的操作的集合,本质上是基于方法视图的封装
    """
    queryset = User.objects.all()
    serializer_class = UserSerializer

    @detail_route(methods=['post'], url_path='change-password')
    def set_password(self, request, *args, **kwargs):
        """
        修改用户的密码
        """
        return Response(status=status.HTTP_200_OK)

    @detail_route(methods=['post'], url_path='change-username')
    def change_username(self, request, *args, **kwargs):
        """
        修改用户的用户名
        """
        return Response(status=status.HTTP_200_OK, data={'msg': 'changed'})

# account/urls.py
router = routers.SimpleRouter()
router.register(r'', views.AccountViewSet, base_name='user')
urlpatterns = router.urls

以上代码,直接实现了对account的增(create)删(delete)改(update)和account列表(list),同时我又添加了set_password和change_username方法。这种形式没接触过的话很难理解,但是却很实用,尤其一个model有频繁的不同功能需求的时候,如果写SetPasswordView和ChangeUsernameView这样类视图的实现,未免会很麻烦,这个时候viewsets就是很好的选择。

Serializers

class TopicListSerializer(serializers.ModelSerializer):
    class Meta:
        model = models.TopicModel
        fields = '__all__'
        read_only_fields = ('id', 'author_id')

Serializer相当于View和Model的中间层,避免view频繁直接操作model object的同时,规范数据字段格式、内容、validator、提供序列化数据等等,同时可以定义方法实现对model的特定操作。serializer不适合处理业务逻辑,它要做的就是对数据传入传出的处理,保证数据正确。通常为了验证和序列化各项数据,serializer的代码加上validator也集中了较大的工作量。

其它
drf最主要的就是上面提到的一些概念,也许在刚接触Django Web的话没有接触过,但是这应该是drf中最常用的。其他的比如router、Throttling、validator也比较实用,甚至也是必须掌握的,但是drf的文档写的确定很详细,使用方法不再介绍。

总结
我的理解,drf是基于“Don’t repeat yourself”原则,提出一个Web开发的规范,它代码里提供了规范的接口,和最基础的使用例子,而在实际的复杂逻辑开发中,需要的是对各种概念的“custome”定制,几乎文档每一页都提供了定制的介绍。实际的应用里面不会是简单的增删改查,而是需要走一定的逻辑处理后的增删改查,同时还有对基础操作频繁的复用。drf通过把web业务系统中会出现的每一步流程拆分,进行模块化,概念化,让开发者知道需要开发的业务属于哪一种概念,放到哪一个模块下面,从而在drf的大框架下特定的位置编写,这样减少了一份功能多份代码实现的麻烦,也因为规范化coding提高了开发者的效率。

当然drf也有缺点,它对新手不够友好,一些封装太极致,以至于不容易明白程序的执行流程,比如我初次看viewsets、GenericAPIView的时候。