django class-based view 考古

django 中的view中进化史：

　　1、在“天地初开”的时候django中的view是通过函数来定义的、函数接收一个request并以一个response作为返回；

　　对于这个request是通过post、get、head还是别的什么方式来到服务器端的、要在函数中进行测试，然后就可以

　　针对不同的请求进行不同的处理了; 一个典型的通过函数定义的View看起来像下面的样子

def MethodTest(request,*args,**kwargs):
    if request.method=='GET':
        return HttpResponse("这是一个get请求")
    elif request.method=='POST':
        return HttpResponse("这是一个post请求")
    else:
        return HttpResponse("others")

　　这样写代码要面对的问题 1):如果view一多就会出现许多重复的代码、比如说上面函数中对请求类型的测试；2):不利于代码的重用；

　　为了解决“重复”和“代码冗余”的问题，基于“class”的View就出现了。

　　2、django把一些能用的代码“抽象”到了View这个类中、如果我们定义的view都继承自这个类、那么也就可以重用这部分代码了；

class MethodTest(View):
    def get(self,request,*args,**kwargs):
        return HttpResponse("这是一个get请求")

    def post(self,request,*args,**kwargs):
        return HttpResponse("这是一个post请求")

　　不同的请求走不同的方法进行处理、事实上View类上有一个dispatch方法在这个方法中对request.method进行测试、然后根据不同

　　的请求方法调用不同的方法。

　　3、class based view的进化并没有停止下来、原因是开发人员所编写的业务逻辑有非常大的一部份是重复的、比如说几乎每一个人都

　　写过“表单处理”、“增、删了、改、查”这类的逻辑、django把这样的逻辑再次抽象并封装到了generic view 中去；通过generic view

　　去开发业务逻辑、大大的加快了开发的速度。

　　以下是我的个从网站(蒋乐哥哥的官方网站www.sqlpy.com)中一个完整的“增”功能对应的view

class TuningItemCreateView(CreateView):
    """
    """
    form_class=TuningItemForm
    template_name='sysbench/tuningitem-create.html'

　　可以看到业务逻辑的处理已经全自动化了、简单到没有朋友呀！

　　

------

我的个人网站：http://www.sqlpy.com

----