Django 的 class based views 比函数 views 对比，有哪些好处？有没有用 cbv 开发的例子？多谢。

[icecream187]

Django的class based views比函数views 对比，有哪些好处？有没有用cbv开发的例子？多谢。

[virusdefender]

好处大致就是能省了给很多函数起名字 还有区分 post 和 get什么的

[happywowwow]

如果模型简单，需求简单还是可以用用吧? ——个人拙见
之前也学了一阵，设计个博客，也觉得cbv好高大上，讲了这么多，但后面自己写着写着，发现还不如不用，强迫自己的逻辑套到cbv里太麻烦了

[icecream187]

@happywowwow 复杂逻辑的页面就不适合用cbv了吗》？

[happywowwow]

@icecream187 不敢妄下断言
只能说，我边学边写的时候，越来越觉得cbv用起来累，不断地要重写父类里的函数
另外，cbv代码其实挺简单的，看完自己写一套自己适用的也不难吧

[geeklian]

完全是习惯问题吧，但习惯了就停不下来了啊。

主要是继承省事啊

我习惯django自带View》项目的BaaeView》应用的AppView》页面的PageView逐级继承。

共通的内容都少些点，PageView里逻辑代码占的比例更大。

这是我项目常用的BaseView，鄙人不是职业程序员，写点东西就是为了方便自己工作。

https://github.com/geeklian/CGB-BFSS/blob/master/public/views.py

[tini9]

面向对象
函数式编程
restful
single page
nosql
TDD
工厂模式
元编程
nosql
。。。。。。。

还有多少被程序员当作圣旨给用到死胡同的技术？

[tini9]

刚学Python的时候，不用装饰器都不好意思给人打招呼
刚学ruby的时候，不用元编程都不好意思给人打招呼
刚学django的时候，入过signal的坑，最后发现费这事干嘛，用函数调用不就行了吗。

[rcmerci]

写个好的父类会省很多事

[adieu]

最大的区别是function based view整个view的逻辑被包在了一整个function里面，要实现view的复用，只能定义很多的参数，然后在view当中用参数判断来执行不同的逻辑。当参数多了，整个view就会变得非常巨大以及难以维护。

而class based view则将整个view的逻辑拆成了class下的多个函数，依靠函数调用来实现完整的逻辑。复用的时候要修改某一部分的逻辑就只需要重载特定的函数就可以了，可以写出复用性更好的view，同时项目当中也可以根据要求实现重载，更加灵活。

当然class based view也不是万能的，当继承关系很复杂，代码又不是特别规整的时候，要去找某一个函数到底是被哪一个parent重载也是一个麻烦事。这个时候就会怀念全部写在一起的function based view了。

所以还是要理解当中的区别，在合适的时候用合适的方法，千万不要听说某个方法好，就把它奉为唯一。

[yueyoum]

@tini9

虽然signal 是同步调用， 但是你还是没理解 signal

signal 是为了 解耦


比如用户干了某件事情， 你只要发出这个 signal 就行
至于收到这个signal后怎么处理， 你完全不关心，


接受这个 signal的处理逻辑也完全不关心这个信号是从哪发出来的。

你是不是觉得 函数调用 也能达到这样的效果？
是的，只是代码混乱而已

经典场景： 数据展现层 和 逻辑处理层，

数据展现层 接受用户输入， 发出信号 A
逻辑处理层 接受其他输入或自己内部变化，发出信号B

数据展现层监听B信号， 自己更新UI
逻辑处理曾监听A信号， 处理输入信号


完完全全分离， 清晰明了。 要扩展也是分分种的事情

[yueyoum]

@happywowwow

说明你用错了， 你的使用场景就类似与这样：

Person 和 Food 这两种完全不一样的东西，
你非要写一个 基类 让 Person 和 Food 继承自那个基类

所以你要在 Person 和 Food 里面写各自的东西， 共用的东西很少
所以你觉得累

[tini9]

@yueyoum 逻辑信号处理，那只是理论，实际上在web后台中，只有一条线索的流水线式结构，最适合梳理业务逻辑。

信号、监听、句柄这些理念适合传统的桌面开发，用在web上会吧简单的问题复杂化。

[yueyoum]

@adieu

同意你的观点

总之 怎么方便怎么来，Class Based View 也不一定要继承自 Django 自己的 View
比如 这个： https://github.com/yueyoum/lockscreen-image/blob/master/project/apps/image/views.py

自己的 Class Based View 让多个url 映射到其上， 为了仅仅是共用代码和逻辑而已

自己的风格是 函数 和 Class Based Views 混用

[tini9]

@adieu 业务逻辑封装是万恶之源，除非是上帝，以人类渺小的智商根本无法抽象这现实世界。业务逻辑封装，往往是为了一步复用，要走上十步的弯路。老老实实的把view分开写，互不干扰，是最便捷的方案

[yueyoum]

@tini9

多做点项目， 你会发现 django 的 signal 根本不够用，
你需要 message queue

[yueyoum]

@tini9

>> 刚学Python的时候，不用装饰器都不好意思给人打招呼

那你现在 用不用 装饰器？ 好不好用呢？

[tini9]

@yueyoum 框架中有提供的当然会用，但不会自己实现装饰器，没有非用装饰器实现不了的需求。

[tini9]

@yueyoum
多做点项目， 你会发现 django 的 signal 根本不够用，
你需要 message queue
============================================
不要想当然，我已经过了追求各种概念的阶段

[yueyoum]

@tini9

你说的虽然是正确的，但并不是合理的

无意义的口水 也不必了， 多看看别人的代码， 多做几年项目
然后再回来看自己当时的言论。

[yueyoum]

@tini9

>> 不要想当然，我已经过了追求各种概念的阶段
>> 逻辑信号处理，那只是理论，实际上在web后台中，只有一条线索的流水线式结构，最适合梳理业务逻辑。


只有一条线索的流水线式结构？


一个人发了一个 twitter, 他所有的 followers 都要及时看到， 并且每个follower对这个新 消息都有各自不同的操作。

一条流水线？

[neoblackcap]

@tini9 我用signal主要是在异步回调，以及model pre_save之类的内置signal方法。这些地方若是都换成函数回调，恐怕之后不好维护。

[icecream187]

多谢各位

[adieu]

@tini9 你说的有道理，所以不能乱用封装，把所有东西都揉在一起。

但是django以及django的第三方库解决的一个核心问题是快速开发。把各种功能封装成一个个独立的app，然后开发者只需要根据自己的需要来使用是django的开发模式。那如何解决在app当中实现业务逻辑，在项目中根据需要来设置以及重载是django作为一个框架需要解决的问题。而class based view则是解决这个问题的一个办法。

另外 @yueyoum 提到的signal解耦也是为了app的复用，独立app是不可能知道使用它的项目环境的，也不可能主动来调用项目的代码，这个时候就需要使用signal来把各个app整合起来。

[happywowwow]

@yueyoum
我是使用场景不类似于你所说的