Question

如何Django的View类工作

Answer 1

这些views的基础涉及相当高级的Python，所以如果你是一个初学者，相对的，如果你发现这个代码，这并不奇怪
您应该明白最主要的是什么@classmethoddecorator上做的定义as_view()。那是不是这就是所谓的类的一个实例（以及在需要实例作为self但是这就是所谓的类本身（并采取了类作为cls语言是指，作为一个虽然在Python中，这是一个第三类 CodeGo.net，我们不需要在这里赘述了。
这是一个怎样的看法是在URLconf中定义。你把正确WelcomeView.as_view()-这是什么做的是调用as_view在该URL配置是导入的。
因为我们知道，从点1，cls是视图类本身。正常的一类，当你调用它，你会得到一个对象。所以，就像你说的，我们在这里做的是什么实例化的类，然后分配该实例名为变量self，仿佛我们是该实例的内部。这里的要点是，正如我上面所说，as_view被称为在导入和它返回一个函数-view-这是反过来调用的URL调度，当浏览器请求的URL。因此，该函数内部，我们构建和调用类的其余部分，构成了基于类的视图。至于为什么需要它，请参阅下文。
该__init__方法利用设置的护理initargs以一个实例属性，在这里你可以通过访问它在你的视图代码self.whatever语法。
那么，为什么这一切有必要吗？

基于类的观点具有巨大的潜力疑难杂症，这是任何类别直接在URL配置（或其他地方在模块级别）实例化将会持续整个过程的全部。而且Django的部署方式-通过WSGI-一个进程可以持续很多很多的要求。如果你已经在多个请求坚持，你有真正讨厌的线程安全漏洞的概率-如果你设置为一个请求一个实例属性，例如，它会显示在后续的请求。
因此，这段代码不仅保证了每个请求得到一个新的实例，这也使得它真的很难通过动态构造实例的每个视图函数内打破这一要求隔离。

Answer 2

router部分，把request对象组装好，根据url配置找到对应view，然后把request和相关参数(如何定义的话)传给view函数，最后view函数的输出返回给客户端或者浏览器。