作者：不详 来源：JavaEye 酷勤网收集 2008-04-22
摘要
恨Django的5个理由：Ajax很难和Django一起用；缺少identity map;NewForms非常有限，配置信息混淆了公共信息和隐秘信息。爱Django的5个理由：很棒的Admin interface；内容全面更新及时的文档；社区的支持；很多可重用的组件/插件；让事情变得容易，让不可能变为可行
我恨Django的5个理由
虽然我喜欢Django,但是无论如何它也有瑕疵的，让我先把"丑话"说在前面吧.
Ajax很难和Django一起用
大部分的Django社区都认为把Javascript helpers和python framework放到一起并不是个很好的主意。虽然我理解Javascrip是基本知识，人人都懂得一些，但是我仍然不赞同这个主意。SQL和Javascript一样也是基本知识，但是我们仍然要ORM来提炼出共用和重复的内容。
当然，通过simplejson和JQuery，能够快速的建立Ajax应用。但是在Python和Javascript之间频繁切换让
人很头痛。
缺少identity map
如果你用Model.objects.get从某数据库中两次获取相同的一行，你会得到不同的对象.除了两次查询的性能问题以外，当你只需要更新其中一个对象而另外一个不更新时，你会发现很有意思的事情。另外，你如果同时更新两者，数据库可能会出现前后不一致的结果。
这里是一个例子:
你可以在settings.py里面设置SESSION_EXPIRE_AT_BROWSER_CLOSE 来定义session类型。但是你不能按用户设置他们。这虽然是个次要问题，但是你仍然不得不每个应用都这样弄下，我好像记得不这样做的话，函数是不能运行的。
NewForms非常有限
比如你需要form包含不定数量的field.你会如何用NewForms类来做这个事情
这样只能创建固定数量的field.当然也有方法来创建不定数量field，但是并不很容易或者说不容易优雅的实现这一点。
配置信息混淆了公共信息和隐秘信息
比如我发布一个应用，里面有一个MIDDLEWARE_CLASSES参数，我不希望别人修改这个。同样的，大部分情况下，INSTALLED_APPS，应该是用户不能修改的，(除非你发布独立应用)。这意味着必须对 settings.py 进行版本管理，但是里面又包含了数据库信息，和 SECRET_KEY 之类的不能够进行版本控制的内容，这又表明不能对settings.py进行版本控制。
就 os.environ['DJANGO_SETTINGS_MODULE'] = 'settings' 这句来说，settings.py需要重新制定。
另:
两个曾经困扰我的问题已经解决:
1.不能继承Models。现在可以用query-refactor完成。
2.URL和View的映射曾经是个问题，但是regexes外美的解决了这个问题。
我爱Django的5个理由
说完了我讨厌Django的理由，下面该说说我为什么喜欢Django了:
很棒的Admin interface
我曾经给一些人演示过Django,在models.py写几行代码就可以生成Admin interface,让人惊讶得下巴都快掉了.每次演示都是这么简单,在这里,你可以看到很多人都不相信这么简单,并且怀疑里面是不是隐藏了代码.
当然Admin不只是炫耀的工具,当我做一个新的站点的时候,我会先写views来查询数据库,所以Admin是不可或缺的.在大部分情况下,写写Model,玩玩Admin对我来说就足够了.
内容全面更新及时的文档
当时我在网上寻找python框架找很久,最后不得不在Django和Turbogears中间选择一个.由于Django的文档写的更好,而且还有更多的教程,所以最后我投向了Django的怀抱.
社区的支持
无论我在django-users和IRC#Django问什么问题,都能得到很多热心的回复帖子.据我所知很少社区有这样的文化,所谓的牛人都很愿意帮助新人.
很多可重用的组件/插件
django-mptt 可以用来进行对关联性数据的处理,如果需要做一些投票,注册或者wiki之类的小功能,可以到这里去看看.
让事情变得容易,让不可能变为可行
如果需要做一些查询如:SELECT * FROM ... WHERE ..., 就用Model.objects.filter. 如果你需要查询大量关系类型数据的话,那么可以用select_related.如果你需要对一个关系建模,而Django ORM用不上的话,那么可以在extra写sql的方式.有很多GROUP BY或者UNION ALL之类的SQL要处理? 可以试下connection.cursor.根据你的需要,这些小东西可以让你做的事情变得很简单.
和模版的观念类似,如果你需要替换变量的话,这里有{% for ... %}和{{ ... }}可以使用.如果是更复杂的模版,则可以使用模版标签.
我的分析有道理吗？那么你是爱Django还是恨Django呢？理由是什么？
虽然我喜欢Django,但是无论如何它也有瑕疵的，让我先把"丑话"说在前面吧.
Ajax很难和Django一起用
大部分的Django社区都认为把Javascript helpers和python framework放到一起并不是个很好的主意。虽然我理解Javascrip是基本知识，人人都懂得一些，但是我仍然不赞同这个主意。SQL和Javascript一样也是基本知识，但是我们仍然要ORM来提炼出共用和重复的内容。
当然，通过simplejson和JQuery，能够快速的建立Ajax应用。但是在Python和Javascript之间频繁切换让
人很头痛。
缺少identity map
如果你用Model.objects.get从某数据库中两次获取相同的一行，你会得到不同的对象.除了两次查询的性能问题以外，当你只需要更新其中一个对象而另外一个不更新时，你会发现很有意思的事情。另外，你如果同时更新两者，数据库可能会出现前后不一致的结果。
这里是一个例子:
Js代码 
- See this code
- In [2]: from django.contrib.auth.models import User
- In [3]: usr1 = User.objects.create_user('ram', 'demo@demo.com', 'demo')
- In [4]: usr2 = User.objects.get(username='ram')
- In [5]: usr3 = User.objects.get(username='ram')
- In [6]: user2 == user3
- —————————————————————————
- NameError Traceback (most recent call last)
- …
- In [7]: usr2 == usr3
- Out[7]: True
- In [8]: usr3.username = 'not_ram'
- In [9]: usr3.save()
- In [10]: usr2.username
- Out[10]: u'ram'
- In [11]: us3.username
- —————————————————————————
- NameError Traceback (most recent call last)
- …
- In [12]: usr3.username
- Out[12]: 'not_ram'
- In [13]: usr2 == usr3
- Out[13]: True
See this code
In [2]: from django.contrib.auth.models import User
In [3]: usr1 = User.objects.create_user('ram', 'demo@demo.com', 'demo')
In [4]: usr2 = User.objects.get(username='ram')
In [5]: usr3 = User.objects.get(username='ram')
In [6]: user2 == user3
—————————————————————————
NameError Traceback (most recent call last)
…
In [7]: usr2 == usr3
Out[7]: True
In [8]: usr3.username = 'not_ram'
In [9]: usr3.save()
In [10]: usr2.username
Out[10]: u'ram'
In [11]: us3.username
—————————————————————————
NameError Traceback (most recent call last)
…
In [12]: usr3.username
Out[12]: 'not_ram'
In [13]: usr2 == usr3
Out[13]: True
你可以在settings.py里面设置SESSION_EXPIRE_AT_BROWSER_CLOSE 来定义session类型。但是你不能按用户设置他们。这虽然是个次要问题，但是你仍然不得不每个应用都这样弄下，我好像记得不这样做的话，函数是不能运行的。
NewForms非常有限
比如你需要form包含不定数量的field.你会如何用NewForms类来做这个事情
Java代码
- from django import newforms as forms
- class MyForm(forms.Form):
- foo = froms.CharField()
- bar = froms.CharField()
from django import newforms as forms
class MyForm(forms.Form):
foo = froms.CharField()
bar = froms.CharField()
这样只能创建固定数量的field.当然也有方法来创建不定数量field，但是并不很容易或者说不容易优雅的实现这一点。
配置信息混淆了公共信息和隐秘信息
比如我发布一个应用，里面有一个MIDDLEWARE_CLASSES参数，我不希望别人修改这个。同样的，大部分情况下，INSTALLED_APPS，应该是用户不能修改的，(除非你发布独立应用)。这意味着必须对 settings.py 进行版本管理，但是里面又包含了数据库信息，和 SECRET_KEY 之类的不能够进行版本控制的内容，这又表明不能对settings.py进行版本控制。
就 os.environ['DJANGO_SETTINGS_MODULE'] = 'settings' 这句来说，settings.py需要重新制定。
另:
两个曾经困扰我的问题已经解决:
1.不能继承Models。现在可以用query-refactor完成。
2.URL和View的映射曾经是个问题，但是regexes外美的解决了这个问题。
我爱Django的5个理由
说完了我讨厌Django的理由，下面该说说我为什么喜欢Django了:
很棒的Admin interface
我曾经给一些人演示过Django,在models.py写几行代码就可以生成Admin interface,让人惊讶得下巴都快掉了.每次演示都是这么简单,在这里,你可以看到很多人都不相信这么简单,并且怀疑里面是不是隐藏了代码.
当然Admin不只是炫耀的工具,当我做一个新的站点的时候,我会先写views来查询数据库,所以Admin是不可或缺的.在大部分情况下,写写Model,玩玩Admin对我来说就足够了.
内容全面更新及时的文档
当时我在网上寻找python框架找很久,最后不得不在Django和Turbogears中间选择一个.由于Django的文档写的更好,而且还有更多的教程,所以最后我投向了Django的怀抱.
社区的支持
无论我在django-users和IRC#Django问什么问题,都能得到很多热心的回复帖子.据我所知很少社区有这样的文化,所谓的牛人都很愿意帮助新人.
很多可重用的组件/插件
django-mptt 可以用来进行对关联性数据的处理,如果需要做一些投票,注册或者wiki之类的小功能,可以到这里去看看.
让事情变得容易,让不可能变为可行
如果需要做一些查询如:SELECT * FROM ... WHERE ..., 就用Model.objects.filter. 如果你需要查询大量关系类型数据的话,那么可以用select_related.如果你需要对一个关系建模,而Django ORM用不上的话,那么可以在extra写sql的方式.有很多GROUP BY或者UNION ALL之类的SQL要处理? 可以试下connection.cursor.根据你的需要,这些小东西可以让你做的事情变得很简单.
和模版的观念类似,如果你需要替换变量的话,这里有{% for ... %}和{{ ... }}可以使用.如果是更复杂的模版,则可以使用模版标签.
我的分析有道理吗？那么你是爱Django还是恨Django呢？理由是什么？