- from the5fire.com在 《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也是一个生态系统，各种丰富的插件，各种现成的应用，只能说一切等你发现。
微信公众号：Python程序员杂谈
