比较过rails和django

从来就没觉得这样的比较很恰当，为什么人们总是把这两样完全不同的东西进行比较。如果说乍看起来很像，那也应该是pylons而不是django，那么稍稍来了解一下pylons吧

Pylons的出现使得python世界之中的另外一个重要的framework TurboGears十分尴尬，Pylons和TurboGears几乎有着完全一致的设计理念，在我的理解中，Pylons实现得更加出色。个人观点：TurboGears可以不用搞了，注意：是个人观点。


Pylons的确是抄袭了很多框架的GoodIdea，在其中我们可以看到很多优秀的设计思想。

TG可能是最初吵着不要重复发明轮子的，于是写了一个脚本把一些它人为不错的东西捆绑了一起。这里面包括CherryPy和SQLAlchemy。Pylons做的更绝，不但绑了，而且绑了很多，比如你可以选择SQLAlchemy也可以选择SQLObject

再来说说和Rails很像的地方，关于Session的处理，它是可以放在各种地方，数据库，文件系统，Rails也是。但是Django不是，全部丢进数据库了，或许将来会有不同的打算。另外URL Dispatch方面Pylons使用的是Routes，它的主页上已经明确表明自己是Rails风格的Dispatcher。最后看看目录结构，和Rails一样让人莫不着头脑，当然仅对新手而言。

事实上，很长一段时间以来，我都没有去仔细了解Pylons。原因是我一直都没有正确的认识到Paste是什么。我自做聪明的认为Paste是一个脚本，但最后我才发现，Paste本身就是一个framework，非常low level的framework。这更加让人拍案叫绝。当TG开始整合各种库的时候，好比自己新写了一个类。但是Pylons从一开始就是继承了一个类，整个工作就在别人的基础上实现了，连自己这个轮子都不再需要被重新发明了。

像基本的输入/输出这样的功能，Pylons就是靠继承Paste得来的，顺便Pylons还得到了一个调式服务器和生成项目需要的脚本，这在几乎所有的框架中都有，Pylons当然也不能少。

接着Pylons需要一些模块来完成它需要的功能：为了实现像rails一样的URL Dispatch，Pylons吸收了Routes。为了实现Session和Cache，Pylons使用了Beaker。当需要模版引擎的时候，Pylons为我们提供了一堆候选者，Mako，Myght，Kid⋯⋯数据库还有SQLAlchemy和SQLObject两个现成的可以使用。Ajax也还有很多选择。

现在，Pylons的结构就大概的呈现在我们眼前了

无数人都把 rails 和 django 当作差不多的东西，有些人甚至用到了 clone 一词

作为一个用户，我喜欢python，于是从而选择django，看起来顺理成章。不过rails真的和django一样吗？我只能努力的去寻找一点不同之处。真的，我很期待可以从中看到不同的想法

很多人都从 ruby on rails 网站上的秀 textmate 的那些视频开始首次接触 rails ，如果不出意外，很多人也是从这里第一次认识ruby。

即使很多人不愿意承认，他们实际上还是被scafford弄的一头雾水。那段视频总是给人以似懂非懂的感觉，有的时候让人觉得是在变魔术。

django的orm是从一个class推导出一个 database scheme ，类似这样的操作在rails 中不存在，人们必须直面SQL语句，或者使用GUI工具。django的方法明显受到了python的orm工具sqlobject的影响，对于初学者略微友好

从某种角度说，rails在某一方面更加体现了DRY，django略逊一筹。当一个数据模型建立以后，scafford给人的感觉是自我感知了这个模型，并自动生成了操作该模型的CURD(Create Update Read Delete)的Views，而使用django的人似乎不容易习惯这样的方式，往往选择手动创建 view 来操作 model

其实django也有从model直接生成view的工具，其实是表单工具。这样实现CU的问题就不是很大。但是和scafford的一站式服务相比，还是显得有些麻烦。不过newform的出现，已经给django增加了不少生产力，或许django已经决定走这种灵活路线的DRY了吧！

花了好长时间才领悟scafford哲学，这就是我不努力学习rails的结果⋯⋯自嘲中！