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
----