Django 有哪些局限性?
程序员文章站
2022-05-13 15:19:26
...
回复内容:
Django的局限性也无非封装太多不够通用,灵活性不够,中间件不遵循WSGI协议自成一套比较封闭,ORM/Template性能不佳。对于初学者而言,不用去考虑其局限性,Django封装的很好,初学者可以很快的做出一个应用。当你真的感到它的局限性已经影响到你时,相信那时你已经有能力跳出它的局限了。
所以不用考虑太多,畏首畏尾的,先做出东西再说,初学者Quick and Dirty没什么羞耻的。 已重写本回答……
Django 最大的问题是它已经为你预想了一套需求,并准备了针对这些需求的功能。在使用的时候,你要做的不是分析需求然后在 Django 的辅助下开发,而是按照手册的指导开启 Django 的这些功能。也就是说,你已经拥有了一把成型的锤子,只能用来钉它能钉的钉子。
如果你的需求不能被 Django 的设计覆盖了,那么你能做的是修改需求,而不是修改应用。因为 Django 已经被重度设计过,再二次修改设计成本很高。
一句话总结:Django 不是框架是应用 对静态资源的管理比 Rails Asset pipeline 差距比较大。不只是官方 staticfiles,包括第三方的 asset manager 插件尝试下来,也都没有 Sprockets 好用,所以最终还是建了一个空的 Rails project 专门处理 Assets,然后让 Django 通过 manifest 文件去调用这些资源。
对 NoSQL 数据库没有官方支持。虽然其他框架好像也没有官方 NoSQL 支持,但因为 Django ORM 和其他组件是深度耦合的,所以如果用一个 NoSQL ORM 替换掉 Django ORM 的话,其他组件等于不能用了。现在有 Django NonRel 的分支可以支持 MongoDB 和其他一些 NoSQL 数据库,虽然很好用,但因为不是官方分支,为了和上游版本兼容,需要付出的很多额外的代价。 django的局限(相对web.py)而言,可能是封装的太多了。因为你可以十分钟内用django建起一个博客(自己百度),但是,同时也意味着它为你在幕后做了很多工作而且可能并不是最优化的。而,Python的思想,我认为, 是显示声明,一切都应该有明确的说明,而不是靠默认操作。因此,django想要做好的话,你可能得深入的了解它,完善它。
如果你已经对它的代码有了深入了解,也许,可以让它变得更好 只要是适合自己的,就是最好的框架。我从django 0.96的时候开始使用一直到现在,可以说一直看着django成长起来。
django被人诟病最多的地方无非就是ORM太重,模板性能太差等等,但是我想说的是这些常被人说三道四的地方,其实django都给出了替代的方案。
ORM:如果你嫌写Model太麻烦,只想执行raw sql,那你可以参考 https://docs.djangoproject.com/en/1.4/topics/db/sql/ ,即使只用这部分,你也可以得到很多好处,不用再关心数据库使用的是MySQL还是PostgreSQL,方便的建立和自动关闭数据库链接。如果你觉得Django的ORM太差,完全可以在这基础之上构建属于自己的一个django的ORM,但是请自己好好考虑sql注入的风险吧。
模板性能:模板只在你返回web请求的时候才会用到,如果你喜欢,完全可以使用其他的模板系统,比如jinja。
如果是想写一个hello world类型的项目,其他轻量级的框架看起来几行代码就实现了。而django需要你先运行 startproject,startapp之类的一堆命令,看上去好像很麻烦。但是随着项目的越来越大,你需要集成的东西越来越多,你会发现django可以为你节省更多的时间。想要一个简单又有一定定制性的后台数据管理?django的admin实在太方便了。想要一个用户注册系统?自带的和网上各种app也是一大堆。想自动处理时区?想有多语言网站界面?等等这些django已经都为你考虑到了。django的django\utils目录也是一个不错的宝库,很多实用的小函数和类经常可以在这里被发现。
如果说非要有什么局限性的话,django和js的结合性确实比rails差很多,自己部署的话也比较麻烦(但是现在已经出现像dotcloud这样的快速部署服务)。 泻药啊,这不是我擅长的,我帮你再邀请几个人吧。
硬要说局限,恐怕最大的局限就是支持 python 的主机相对较少吧。
不过鉴于你初期要用的也就只是一个主机而已,总是找得到的,所以这也不算什么大问题。——如果你到了用VPS或者用物理主机的地步,那这也就更不是问题了,反正想装什么能装什么。 有人对django的局限做过论述,我在此引用一下,可以看下面两篇博文: http://www.cnblogs.com/zhengyun_ustc/archive/2006/11/19/564917.html
http://cookoo.iteye.com/blog/33182 如果每次升级带来的不向下兼容也算的话,那这个是我个人最不满意的局限性了。性能神码的,还是要根据应用来决定。 這兩篇文章, 年代實在有點久遠, 當中提到的 Django 程式碼時常修改, 在這一兩年剛好是反過來的, RoR 常有不向下相容的更新, 身邊許多朋友都長踩到地雷, 而 Django 則是很穩定。
我倒是覺得沒有什麼侷限。 只能用来钉它能钉的钉子。
如果你的需求不能被 Django 的设计覆盖了,那么你能做的是修改需求,而不是修改应用。因为 Django 已经被重度设计过,再二次修改设计成本很高。
上一篇: 事件冒泡是什么如何用jquery阻止事件冒泡_jquery
下一篇: 记一次Oracle坏块修复过程