rest_framework之视图及源码剖析

最初形态(工作中可能会使用)

引子

Django的CBV我们应该都有所了解及使用，大体概括一下就是通过定义类并在类中定义get post put delete等对应于请求方法的方法，当请求来的时候会自动对应相应的方法并执行，urls.py中需要类点as_view()的方式来配置路由，至于如何拿到请求方法并对应执行我们自定义类中的方法，前面的博客中已经有了源码解析，这里不再陈述~

APIView

我们写的类不再继承Django的View类而是继承rest提供给我们的APIView类，这里对于一个数据表的增删改查我们需要定义两个类来处理

class AuthorView(APIView):
    def get():#批量查询
    pass
    def post():#新增一条数据
    pass

class AuthorDetailView(APIView):
    def get():#查询一条数据
    pass
    def delete():#删除一条数据
    pass
     def put():#修改一条数据
        pass    

对应urls.py

urlpatterns = [
    url(r'^admin/', admin.site.urls),
    url(r'^authors/$',views.AuthorView.as_view()),
    url(r'^authors/(\d+)/$',views.AuthorDetail.as_view())
]

过渡

我们来思考一个问题，假设我有十张表，那么根据上面的方法，我需要重复写二十次这样的代码，并且类里面的逻辑路由都是一模一样的，不同的仅仅是表名影响的数据部分，这样的情况是不能允许的，老是重复代码~~~那有没有一种方式可以让我们避免写重复代码，思路就是将这写处理逻辑封装成类方法，我写的类只需要继承封装的类就能调用这些方法即可，还真有对应于我们上面的增删改查封装了这些功能的类

rest_framework.mixins混合类下：

    ListModelMixin         ————————>>>批量查询(get)

    CreateModelMixin    ————————>>>新增数据(post)

    UpdateModelMixin    ————————>>>更新数据(put/patch)

    RetrieveModelMixin    ————————>>>查看单条数据(get)

    DestroyModelMixin    ————————>>>删除单条数据(delete)

那么我们自己写的类只需要继承这些类就可以直接调用他们下面的方法，这样就省去了相同的增删改查逻辑

class AuthorSer(serializers.ModelSerializer):
    class Meta:
        model = models.Author
        fields = '__all__'

class AuthorView(ListModelMixin, CreateModelMixin, generics.GenericAPIView):
    queryset = models.Author.objects.all()
    serializer_class = AuthorSer

    def get(self, request, *args, **kwargs):
        return self.list(request, *args, **kwargs)

    def post(self, request, *args, **kwargs):
        return self.create(request, *args, **kwargs)

class AuthorDetailView(RetrieveModelMixin, UpdateModelMixin, DestroyModelMixin, generics.GenericAPIView):
    queryset = models.Author.objects.all()
    serializer_class = AuthorSer

    def get(self, request, *args, **kwargs):
        return self.retrieve(request, *args, **kwargs)

    def put(self, request, *args, **kwargs):
        return self.update(request, *args, **kwargs)

    def delete(self, request, *args, **kwargs):
        return self.destroy(request, *args, **kwargs)

对应的urls.py路由

urlpatterns = [
    url(r'^admin/', admin.site.urls),

    url(r'authors/$',views.AuthorView.as_view()),

    url(r'authors/(?P<pk>\d+)/$',views.AuthorDetailView.as_view())
]
#这里必须注意需要给后面这个匹配数字的匹配式起一个别名'pk'有且只能叫'pk'这个名字，不然会包缺少pk这个关键参数

演变

上面的过渡确实让我们省去了重复写增删改查逻辑，但是依然有较多的重复代码~~~站在面向对象的思想高度上，能不能再对其进行一层封装让我们连定义方法都不用了呢？

初步思想就是一个类封装了批量查看和新增方法，另一个类封装了针对单条数据的查，改和删。。。。。。

唉~还真有哦，只有你想不到没有我们程序员做不到的~还是继承类，并且这个类你一眼就能看出它想干嘛

from rest_framework import generics

class PublishSer(serializers.ModelSerializer):
    class Meta:
        model = models.Publish
        fields = '__all__'

class PublishView(generics.ListCreateAPIView):
    '''
    ListCreateAPIView:集成了List Create APIView于一身
    '''
    queryset = models.Publish.objects.all()
    serializer_class = PublishSer

class PublishDetail(generics.RetrieveUpdateDestroyAPIView):
    '''
    RetrieveUpdateDestroyAPIView:集成了Retrieve Update Destroy APIView于一身
    '''
    queryset = models.Publish.objects.all()
    serializer_class = PublishSer

相当于在过渡阶段的基础上对类又做了一层封装~~~

究极进化版

如果你认为上面的演变版本已经是最终版本，那你怕是小看了程序员的偷懒能力了，能少敲一个字母绝不会多敲一个！！！

上面的演变版本仍然有重复的代码部分，并且对于一张表我们需要写两个类，这样太麻烦了，能不能将两个类合成一个类呢？

你可能会想合成一个类的话，那我的批量查看get和单条查看get怎么区分？？？

别急 我们先把最终版本写上，一会儿我们去看看从上之下，从最终的屌丝版本怎么一步步封装成了究极恐怖版本！

from rest_framework.viewsets import ModelViewSet

class AuthorDetailSer(serializers.ModelSerializer):
    class Meta:
        model = models.AuthorDetail
        fields = '__all__'

class AuthorDetailsView(ModelViewSet):
    queryset = models.AuthorDetail.objects.all()
    serializer_class = AuthorDetailSer

上述例子所有的路由

urlpatterns = [
    url(r'^admin/', admin.site.urls),
    url(r'^books/$',views.BookView.as_view()),
    url(r'^books/(?P<pk>\d+)/$',views.BookDetail.as_view()),

    url(r'^authors/$',views.AuthorView.as_view()),
    url(r'^authors/(?P<pk>\d+)/$',views.AuthorDetailView.as_view()),

    url(r'^publishes/$',views.PublishView.as_view()),
    url(r'^publishes/(?P<pk>\d+)/$',views.PublishDetail.as_view()),

    url(r'^authordetail/$',views.AuthorDetailsView.as_view({"get":"list","post":"create"})),
    url(r'^authordetail/(?P<pk>\d+)/$',views.AuthorDetailsView.as_view({"get":"retrieve","put":"update","delete":"destroy"}))
]

这里需要着重拿出来说的就是，它是怎么做到区分两个不同get的，一会儿看源码就知道他是将原本的方法都起了别名

get批量查询         ————对应—————    list方法

post新增数据        ————对应—————    create方法

get单挑数据查询        ————对应—————    retrieve方法

put单条数据更新        —————对应————    update方法

delete删除单条数据    —————对应————destroy方法

在路由是两条的情况下，这已经是究极体了，路由不能也不可能简化成一条！！！

源码剖析

APIView源码部分之前的博客已经解析过了，这里就不再赘述，直接从过渡版本开始~

需要知道是为什么会有过渡版本，是站在我们想简化代码，封装相同的逻辑代码块，首先就是对方法的封装，一个类封装一个方法~

下面我们就去这些类里面看看它们做了什么~

那过渡版本的书写格式的由来就阐述清楚了，接下来看演变版本又是怎么做的

上面几个好像并不能解释清楚到底怎么回事，接下来的究极版本就会有清晰的认识！！！

同样这个类方法返回的是view函数名，也就意味着只有不访问到这个路由，函数view就不会被执行，但是一旦开始访问了，那么就会去执行view函数内的代码