Jeff的妙想奇境

产品经理,技术爱好者(Java, Django 等),音乐教师,好老公…… ...

↑我也要推荐

Django是完备的

发布时间:2013-08-18 23:20:43, 关注:+6820, 赞美:+18, 不爽:+10

原始出处: the5fire的技术博客

在 《Django是否太重了》 一文中,我提到了在完成简单任务的时候会觉得用Django这样的东西确实是太重了。但是当你要做一个功能完备的CMS系统时,你又会觉得其他的太轻了,轻到你会觉得这些CRUD的代码本来就该机器来生产,为毛还要自己写。

因此在此提醒大家,看别人的文章时,尤其是具有明显导向性的文章时要保持自己独立的意识,要了解哪些是客观的,哪些是当事人场景下的。

之前有说过,我们在为新项目做技术选项,现在已经确定用Django来做。之前在Tornado和Django中选择主要考虑在性能部分,Tornado有天然的优势,也是唯一的优势——非阻塞,除此之外好像没有其它值得考虑的地方。

反观Django两个显而易见的缺点:性能和学习成本。性能主要的缺陷在于,一个通用的框架为了把各个部分都组件化,必然会损失一些性能上的要求。其中饱受诟病同时也方便操作数据库的ORM层也拖了性能的后腿。不过好的代码和差的代码效率还是差挺多的,Django的文档上也有专门的部分来讲如何优化代码: 《Django1.4数据库访问优化-翻译》 。另外Django的模板引擎也是效率比较低的部分。好在Django提供了一套缓存框架(机制),大到站点级别的缓存,小到你直接对任何元素的缓存。可以缓存你的整站、模板、view。加上这些基本能让Django减压不少。

但是,上述的性能方面内容和解决方案都免不了你要去学习Django的文档,甚至是去阅读其源码。对于Django这样文档驱动型的框架,基本上把文档过一遍之后一切都好说了。文档驱动是好事,文档全也是好事。只不过想起我在ipad中放到那一千多页的文档心里也挺犯怵。要用好Django需要相当大的学习成本。可一旦完全了解之后必然会大大的提高开发速度。

利和弊往往是相伴而生,妄想得到一个完美的框架是不可能的,但任何一个框架都有其使用的场景,如tornado就适合这样高负载的场景,而Django这个诞生于新闻站点的框架必然也擅长于处理新闻内容(CMS)。因此抛出性能不说,对于一个内容管理方面的站点来说Django基本上是完备的,有了Model基本上后台就可用了。不过话说回来,基于Django的高负载站点也有很多。最后给的继续学习的链接中会提到。

在讨论对Django和Tornado的选择中,我们假设选择Tornado,必然要选择一个对应的ORM框架(SqlAlchemy),然后也会选择一个模板语言(mako),然后组装到最后不过是一个基于异步IO的类Django框架。

但是对于非CMS系统来说意义就不同了,比如说只是做一个内容呈现的网站,基于非关系数据库,用Tornado就非常合适,不要ORM,只需要tornado+一个模板语言(或者就用tornado自己的),一切都搞定。这样一个开放型的结构,不需要处理关系,只要针对具体的业务来完成数据读取--渲染--呈现就完了。

今天在网上看到一条言论:Django其实是个app。这么说其实有点问题,wordpress那样的才算是应用,而Django只能说是接近应用的框架,用它能很快的开发出一个应用。同时和wordpress这样除了是应用也是一个生态系统一样,Django也是一个生态系统,各种丰富的插件,各种现成的应用,只能说一切等你发现。

最后分享一个链接: Django-Tips,Tricks and a little Python Magic

如果你觉得本站对你有帮助,欢迎向本站赞助 :P

使用支付宝捐赠

Copyright© Python4cn(news, jobs) simple-is-better.com, 技术驱动:powered by web.py 空间主机:Webfaction

版权申明:文章转载已注明出处,如有疑问请来信咨询。本站为 python 语言推广公益网站,与 python 官方没有任何关系。

联系/投搞/留言: en.simple.is.better@gmail.com 向本站捐赠