CVB生命周期（APIView源码解析）

Django项目中的代码如下

• urls.py中:

from django.conf.urls import url
from app import views

urlpatterns = [
    url(r'^test/$', views.APIViewSourceCode.as_view()),
]

• views.py中:

from rest_framework.views import APIView
class APIViewSourceCode(APIView):
    def get(self, request):
        pass
    def post(self, request):
        pass

APIView源码解析

1.启动Django项目

2.加载settings.py文件

3.读取models.py文件

4.加载views.py文件

5.加载urls.py文件

6.执行urls.py文件

7.执行views.py文件中的APIViewSourceCode类中的as_view()方法

由于APIViewSourceCode类中没有as_view()方法, 于是去APIViewSourceCode的父类APIView中寻找as_view().

8.点击进入APIView源码:

rest_framework\views.py文件中下的 class APIView(View):

可以看出, APIView源码中的as_view()方法会去执行它父类(View)的as_view方法.

9.点击进入APIView(View)的父类View源码:

View的源码是这样的:

• 第一部分:

• 第二部分:

• 总结: 从View的源码中可以分析出, 执行View的as_view方法意味着要去执行当前调用对象的dispatch方法.

10.由于当前调用对象是我们自定义的CBV,所以我们去自定义CBV中寻找dispatch方法

很显然, 我们自定义的CBV中没有dispatch方法, 于是我们去APIViewSourceCode的父类APIView中寻找dispatch方法:

可以看出, APIView重写了它的父类View的dispatch方法, 在APIView的dispatch方法中, 它对最开始自定义CBV的request进行了初始化, 目的是为了给最初的request添加额外的功能. 那么我们现在去initialize_request中看看到底添加了什么额外的功能.

11.点击进入initialize_request

initialize_request最后返回了一个Request对象, 该对象接收了自定义CBV中的request. 我们再来看看这个Request对象进行了什么样的处理.

12.点击进入Request对象中

源码解析总结

弄清楚Django的request对象被添加了什么新功能(属性)

---

• request.query_params可以拿到原来URL里面的参数
• request.data可以拿到前端提交过来的所有数据
• 等等(待续...)

---

---

Django项目中的代码如下

• urls.py中:

from django.conf.urls import url
from app import views

urlpatterns = [
    url(r'^test/$', views.APIViewSourceCode.as_view()),
]

• views.py中:

from rest_framework.views import APIView
class APIViewSourceCode(APIView):
    def get(self, request):
        pass
    def post(self, request):
        pass

APIView源码解析

1.启动Django项目

2.加载settings.py文件

3.读取models.py文件

4.加载views.py文件

5.加载urls.py文件

6.执行urls.py文件

7.执行views.py文件中的APIViewSourceCode类中的as_view()方法

由于APIViewSourceCode类中没有as_view()方法, 于是去APIViewSourceCode的父类APIView中寻找as_view().

8.点击进入APIView源码:

rest_framework\views.py文件中下的 class APIView(View):

可以看出, APIView源码中的as_view()方法会去执行它父类(View)的as_view方法.

9.点击进入APIView(View)的父类View源码:

View的源码是这样的:

• 第一部分:

• 第二部分:

• 总结: 从View的源码中可以分析出, 执行View的as_view方法意味着要去执行当前调用对象的dispatch方法.

10.由于当前调用对象是我们自定义的CBV,所以我们去自定义CBV中寻找dispatch方法

很显然, 我们自定义的CBV中没有dispatch方法, 于是我们去APIViewSourceCode的父类APIView中寻找dispatch方法:

可以看出, APIView重写了它的父类View的dispatch方法, 在APIView的dispatch方法中, 它对最开始自定义CBV的request进行了初始化, 目的是为了给最初的request添加额外的功能. 那么我们现在去initialize_request中看看到底添加了什么额外的功能.

11.点击进入initialize_request

initialize_request最后返回了一个Request对象, 该对象接收了自定义CBV中的request. 我们再来看看这个Request对象进行了什么样的处理.

12.点击进入Request对象中

源码解析总结

弄清楚Django的request对象被添加了什么新功能(属性)

---

• request.query_params可以拿到原来URL里面的参数
• request.data可以拿到前端提交过来的所有数据
• 等等(待续...)

---

---