初识django, 一起进入python的世界吧

[size=medium]这几天花了点时间看了一下python世界中的django，正如某大所说，掌握另外一门语言是有必要的，同样我也作出了自己的选择。从这几天的学习中，我确实也发现其他语言及其框架等确实有一种与众不同的感觉。下面我把自己这几天看到的东西稍微作了一下总结，本文并不是django的教程，而是ahuaxuan对django的一些自己的理解，可能有些不成熟的地方，希望大家不要吝惜手中的砖头。


一 django的orm
如果有人问我最喜欢django什么，我会耗不犹豫的告诉你是django的orm，这个想法的产生完全来自于我长时间来积累的对hibernate的“不满”，虽然从理智的角度来看，hibernate做的是非常的正确的，因为它并不是只针对互连网而产生的，它的主要市场应该还是在企业应用上，不过把它用在互联网并非不可以，只不过大家更多的时候会选择ibatis之类，因为不知道hibernate的人总是会说hibernate没有ibatis快（其实我最烦这个，片面的比较是没有意义的）。正是hibernate的目标是打造成java界一个全方位，全能的orm框架，所以的它学习曲线和使用的复杂度日益的提升，要完全掌握好hibernate不是一件容易的事情（不要告诉我你会点crud，知道点lazy load你就掌握好hibernate了），再回头来看django的orm，如果说要把hibernate说清楚需要800页的书，那么要把django的orm说清楚，200页就够了(事实上它的官方文档只有十几页的样子)。下面我举一个我正在做的例子，这里有一个自关联的对象（事实上django的orm是基于model，这点和ror不太一样，有人跟我讲过ror是数据库驱动），这个对象有一个父对象，通常我们的菜单会定义成这样的对象，这样的菜单可以无限级向下扩展：

class Category(models.Model):
    id = models.AutoField('id', primary_key=True)
    name = models.CharField(maxlength=50)
    code = models.CharField(maxlength=50)
    parentCategory = models.ForeignKey('self', 'id', null=True)
    enable = models.BooleanField()
    
    def __str__(self):
        return self.name
    
    class Admin:
        list_display = ('id', 'name', 'code', 'parentCategory')

Category中又定义的Admin是为django的Admin模块服务的。
瞧，我们定义的域模型只需要这些代码就够了，models.Model是父对象，所有的model对象都需要继承这个对象，这个对象提供了很多常用的数据库方法，不过不是基于sql的，还是基于对象的，如同Criteria一样。下面列出常用的一些查询Category的方法。
1，
查询category by id（从页面上传过来的）
2

categoryList = Category.objects.filter(code__contains = “a”,enable = True).order_by(“-id”)[0:5]

，按id倒序，查询enable属性为True的,且code中包含a的category,且取前5个,是不是有很强烈的criteria的味道
3

category.save()

保存或者更新某个category对象（类似saveOrUpdate操作），充血模型，dao消失了。

4

category.delete()

删除某个category对象,当然delete方法也是支持批量删除，比如

categorys.delete()

5 复杂的查询可以使用extra方法，例如：

Category.objects.extra(where=['id IN (3, 4, 5, 20)'])

，还可以使用字符替换法,如：

Category.objects.extra(where=['code=%s'], params=['a'])

当然django的orm提供了很多很常用的功能，这里不一一举例了，注意，这里我说的是提供了很多很常用的功能，至于hibenate中比较复杂的映射策略，在django中我并没有看到。但是我反而高兴我没有在django中找到这个功能，因为django本身的定位是快速的互连网开发，它不需要太多的关注这个领域很少出现的东西，这样带来的优点是学习曲线的降低和开发效率的提高。

二 django的模板
Django的模板可以说是非常的简洁，简洁到我不知道说什么好，简洁到看一下文档就能上手使用，在java中，freemarker和velocity我都用过，最复杂功能最强大的还是freemarker，支持jsp tag的嵌入让我们可以重用很多已经存在的组件，这一点我在之前的文章中也有过比较详细的描述(强强联手，看freemarker和displaytag的结合)，由于了解，才有发言权，django的模板可以说是为互连网应用而诞生的，简洁及快速开发的特点让人情不自禁的喜欢。大多数模板语言的基本语法都是类似的，比如在freemarker中显示值是${}，而在django是{{}}，freemarker中if判断为<#if></#if>，而django中是

{% if msg %}
	Xx
{% else %}
Xx
{% endif%}

再看看在django中渲染模板的方法，有两种:
第一种

def preparePublish(request):
    t = loader.get_template(publishInfo)
return HttpResponse(t.render(Context({'categoryList' : None})))

第二种

c = Context({"categoryList":categoryList})
return render_to_response(indexPage, c)

render_to_response相当于封装了loader.get_template方法而已,所有的一切看上去都是那么的简单,模板无处不在，今天你模板了吗？

插一句题外话，关于jsp的题外话，不管是ruby，还是c++，还是python，在它们的web框架中都使用了模板，java中也有很多模板，我们最熟悉的是freemarker和velocity。这从一个侧面反映出我们web开发中的一个模式，那就是我们的view基本上是基于模板产生的，而jsp这个东西应该来说是时代的产物，在那个混乱的落后的时代产生的，不过很奇怪的是现在还有这么多人抱着它不放。

三 django的form
Django有两种form，一种是自己定义form class，还有一种是通过我们定义的model自动form class。
由于ahuaxuan只做 了一个信息发布的小例子，所以并不能全面的了解或者理解django中form的所有细节，不过从我涉及到的部分来讲，我对django的从模型创建表单的做法确实感到有比较大的局限性，因为很多时候，model中的数据 并不是从页面上来的，在这种情况下，form对象被构造出来之后，ahuaxuan还没有找到修改form中值的方法。
而自定义form类也比较麻烦，就是要写自己的model，这个和我们之前的做法比较不一样，这里的form代表我们java中的value object，model是domain object，在我们的ssh框架中我们通常把value object继承我们的domain object。虽然一堆又一堆的人提出了反对意见，说要把这两个对象分开，因为他们处在不同的层次中，但是从实践经验中，我们可以看到，这样做没有什么不好。而在django中自定义form和model分开的行为可能比较符合一些人的心理。
不过自定义forms也有比较让人称道的地方，在form中我们可以自定义验证规则，同时我们可以根据form对象直接生成页面中的内容，不过这一点其实也有比较麻烦的地方，就是如果要改变样式的时候就比较麻烦。不过总的来说django的form还是比较有特点的，而且一定程度上给我们带来了方便。


四 django的url转发
Django的url转发是基于正则表达式的，有的人叫好，有的人叫差，我就是叫差的那一拨人之一。url转发应该是一个非常清楚，非常明亮的事情，可是用上这个正则表达式匹配的东西之后，我郁闷了，所以我只能回到遥远的过去去绕过这个东东，我不用总可以了吧。

从目前目前掌握的知识来看，django的views里的东西其实是controller，为什么叫views？不得而知，不过一直这么沿用下来了，即使是在自然界，很多表面上去不太一样得东西，其实内部的原理是一样的，我就觉得django的views就是struts1.x中的action，为什么这样说呢，让我们来看看两段比较的代码，第一段是django的，第二段是struts1.x的：

def index(request):
    
    categoryList = Category.objects.filter(enable = True)
    for cate in categoryList:
        informationList = Information.objects.filter(category = cate)[0:5]
        cate.informationList = informationList
        
    c = Context({"categoryList":categoryList})
return render_to_response(indexPage, c)

――――――――――分隔线―――――――――――――――

public ActionForward getSechandIndex(ActionMapping mapping, ActionForm form,
                                         HttpServletRequest request,
                                         HttpServletResponse response)
            throws Exception {
        setBargainIndex(request);
        return mapping.findForward("bargainHome");
    }

从形式上来看，两者出奇的相似，比如说传入的参数等。我们知道python是面向对象的语言，但是事实上它也支持函数编程，如果def定义在class内部，那么就是对象的方法，否则，就可以认为是函数编程了，看看，我们的views里的东西都是函数，views其实是一个模块，这个模块我们可以认为是struts1.x中的action，而views中的函数可以认为是action中的方法。它们是远房亲戚。

那么说到这里，曲线救国的线也找到了，就是struts.1x中DispatchAction，我们只要在url后面追加一个methodName就可以指定我们要调用views中的哪个函数了。代码如下：

def execute(request):
    methodName = request.GET['methodName']
    return getattr(mark.views, methodName)(request)

这个execute方法成为了所有的方法的入口（我们在urls.py中只需要这样定义：

(r'^$', 'inforplatform.bargin.views.execute')）

接着在execute方法中判断methodName的值，然后根据这个值找到对应的函数，再调用它，getattr类似于java中的反射，可以让我们动态调用任何我们想调用的函数（只要我们知道函数名的话）

这样我们在urls.py中只需要定义很少的值(有几个模块就定义几行就够了)就可以完成我们的项目了，以后维护起来也没有这么麻烦和复杂。
一个小小的缺憾是没有自带restful，不过听说有一个插件可以支持。

六 admin
Django的admin功能号称是django的杀手级特性(killer feature)，这一说可以说是恰如其分，毫不夸张的，从我做的这个例子来看，当我做网站的时候，基本上只需要关注前台页面的展示这部分，后台的功能基本上都自动有了，比如我做的例子是一个二手信息发布平台，category是二手信息的类型，还有一个information类，和category是多对一的关系，那么在后台，category和information的crud就自动生产了，由于category本身是一个自关联，所以在admin中 add category的时候，admin会根据我model的定义，自动要求选择一个parentCategory，而在add information的页面上，admin会要求我选择一个category来完成对一个information的创建，而以前在java中，这些工作都需要自己完成，当然也有很多工具可以自动生产crud，不过这些开源的工具基本上都是针对单个model的，而且生成的代码需要很大修改才能真正的把功能跑起来，最重要的一点是不能自动生成关联关系的管理。当然我也见过有公司做了基于数据库驱动的代码生产器，能生成完整可用的代码和页面，也包括关联关系的处理，不过由于语言特性的区别，在开发的时候我们还是要不停的重启server才能显示出效果来，虽然在技术上，为ssh实现这个功能并不难，但是会消耗不少时间在上面，消耗了很多时间的话，很少就有公司将其贡献出来了。所以个人认为django在这个功能上做得还是非常不错的，尤其这个功能可以节省开发者很多的时间。甚至有些时候，项目可以双线执行，用户通过admin输入数据，程序员开发前台，这样，前台功能做完之后，数据也有了，基本可以测试上线了。在需要快速开发的小项目上，这个特性显得尤其重要，因为django产生得时候就是基于这个场景。

当然有时候后台也没有这么简单，不过还好，admin提供了扩展的功能，我们可以自己写扩展的代码，然后集成到admin中去，不过事实上除了能改变admin的模板，我们不能改变任何admin的代码，不过我时常在想，如果admin支持代码自动生成的功能，那岂不是很美妙，我们可以随意的修改后台的功能了，否则我们就需要自己写代码，不如在生成的代码上扩展方便。

要使用admin，必须打开django的权限模块，这里简单介绍一下权限模块，django自带了一个权限模块，这个权限模块中的model对于熟悉权限这块的人来说再熟悉不过了，user，group，permission，user和group多对多，group和permission多对多，在acegi中，我们通常这样定义，user，role，resource，这个和django中的权限是一样的，不过在django中默认的permission的粒度是非常的粗了，是基于model的，如果我们要更细的权限模块，那么就需要自己扩展了。

总的来说admin给我的惊喜大于失望，虽然有点小小的不满意，但是总体来说还是非常赞的

五 部署
在这部分开始之前我也想聊聊之前我们一直在讲，而且将来还一直会讲下去的一个话题――状态。
之前我们一直在讨论，把用户的状态保存在一个集中的地方，尤其是大规模集群部署的情况下，同样，对于django来说亦是如此，可以说这条金科玉律不只是针对某种针对某个语言，某个框架，它应该是更高层次的一种理念。那么我们可以把状态放到什么地方呢，目前一些流行的选择是DB(内存表，或实体表),memcached，或者cookie，但这几种选择并不是可以随便互换的，比如业务数据较多的情况下，放在cookie中不是很合适，因为有可能超出cookie大小的限制，那么放在memcached中，很遗憾，memcached(使用slab的情况下)中也有它自己的限制，如果状态数据大小跨度较大，那么丢数据的情况有可能发生，ahuaxuan很久之前在测试环境下就碰到过这种情况，由于线上memcached开得较大，所以没有出现这种情况，关于这种事件发生得内部原因在ahuaxuan的另外一篇文章中已经有了非常详细的描述。那么放在DB上呢，显然，DB的压力也是我们需要考虑的问题之一。当然除了这些主流的选择之外，我们其他选择还有很多，比如memcachedb，或者timesten，或者其他等等，但是对于状态这种东西，尤其状态数据比较重要的情况下，我们一定要深入研究并理解状态数据的存储技术，否则可能会遇到我们异想不到的情况，比如很久之前我想破头也不会想到memcached是LRU是针对某个slab的(而且我还要插一句，LRU的时候其实并不是遍历slab中的chunk链表，而且只遍历最开始的50个数据而已，这样做纯粹是为了速度)。


目前对django来说基本上有两种部署策略，
第一种是利用mod_python将django运行在apache进程中，还有一种是webserver+fastcgi，这两种方式各有优缺点，在mod_python模式中，我们的webserver必须使用apache，apache在webserver这一领域已经独占鳌头很多年了，市场占有率也是远远的超过其他的webserver，不过近几年来，又崛起了几个其他的webserver，其中比较出名的是ligttpd和nginx，它们都以高性能和低内存消耗对apache发出了挑战，而mod_python是apache的插件，使用这种方式就把我们的webserver限定在apache上了，不过还好apache+mod_python也是非常的稳定的方案了。

第二种就是webserver＋fastcgi，这里的webserver就可以随意选择了，大多数的webserver对提供了对fastcgi的支持，比如我们耳熟能详的lighttpd和nginx，而且据称在很多情况下，FastCGI能够提供比mod_python更为优越的安全性和效能。针对小型站点，相对于Apache来说FastCGI更为轻量级。据称qq的个人空间就是c++加fastcgi实现的，哦，这样做的优势在哪里呢，c++的处理速度将会非常的快，也就是说每个fastcgi处理一个请求将会非常快速，比如使用python需要50毫秒，c++处理这个请求有可能只需要20毫秒（这个例子未必准确，只是为了说明fastcgi的特性），虽然在开发上c++比较麻烦一点，不过在性能上，c++肯定是no1了，从这个例子上我们可以看到，使用fastcgi速度取决于处理一次请求的速度（废话，哪个不是这样）。

我们来看一下使用fastcgi的一般模式：1、WEB服务器收到客户端的页面请求 2、WEB服务器将这个页面请求委派给一个FastCGI 外部进程（WEB服务器于FastCGI之间是通过socket来连接通讯的） 3、FastCGI外部进程得到WEB服务器委派过来的页面请求信息后进行处理，并且将处理结果（动态页面内容）返回给WEB服务器 4、Web服务器将FastCGI返回回来的结果再转送给客户端浏览器。
对我们来说第3步是我们最需要关注的，因为第3步的速度严重影响着整个性能。由于fastcgi是基于进程的，所以，我们要根据我们的应用来开启数量合适的fastcgi进程，多开了是对资源的浪费，少开了就影响性能，这个类似我们在tomcat中开启处理请求的thread一样，只不过tomcat中的request handler thread在配置起来显然更加方便，因为我们只要关注线程池中最大的可以容纳的线程数，最大空闲线程数等就行了。

当然fastcgi对ahuaxuan这类刚刚跨出java世界的人来说有些不爽的地方，因为基于进程的东东共享数据比较麻烦，比如写一个ip查询的组件，功能是这样的，把ip地址库加载到内存，然后根据客户端的ip使用折半搜索改ip所在的城市，用java做非常的方便，先把几兆的数据加载到内存中，然后每个线程都来请求就可以了。而对于fastcgi来就比较麻烦了，需要把这些数据加载每个fastcgi进程中，无辜浪费掉一堆内存。不过有得必有失，因为每个fastcgi只能同时处理一个请求，所以使用fastcgi就基本不需要考虑多线程的问题了。

通过几天时间的学习，确实使我更加了解了python以及django，但是ahuaxuan也知道要掌握
一门语言和技术需要的肯定是不止几天而已，几天可以说只是入门,说的不对的地方恳请大家批评指正.
[/size]

django的orm还是不是很习惯

刚出了1.0，admin的写法已经变了....
url在1.0已经可以直接映射成函数了，不过我没太看不清楚。
其实我觉得url用正则表达式也没什么不好，通常情况下并不会有什么很复杂的正则表达式，所以还是很容易懂的。

我的思想一直被0配置控制着,url配置我认为是可以去掉的,基于规则就行了,比如struts2中的zero configuration,而且我也是一直这样做的,如果能把url的规则更精简些对程序的负担会更小些,维护起来就更方便些.而且我坚信,框架应该向着coc的方向发展.

而对应django1.0,我还没有看过,最希望的是url的改变,包括能增加restful.

python是个介于Java和Ruby之间的语言，比Java要灵活的多，比Ruby又严谨的多。可能是我写惯了ruby代码了，总觉得python代码不如ruby那么好玩。

如果你要介绍django这些最基本的MVT架构，其实是不如Rails那么好用的，但是django的模块化要比Rails好，值得学习。

恩，不错！
不过之前听阿北说过python的包管理不太方便，比如，没有ruby的gem好用，不知道现在的情况怎么样，06年玩过几个月django，忘完了个球！

不了解ruby不知道gem是什么?不过没发现python的包管理有什么不方便.从07年零散学习python,难道以前的包管理不是现在这个样子?

django的orm比较适合快速开发，比如下面的代码描述一个简单的多对多关系，及通常的用户和用户组的多对多关系：

class User(models.Model):
    name = models.CharField()
    email = models.CharField()
    groups = models.ManyToManyField(Group, through='User2Group')

class Group(models.Model):
    groupName = models.CharField()
    groupDescribe = models.CharField()

class User2Group(models.Model):
    user = models.ForeignKey(User)
    group = models.ForeignKey(Group)

上面是定义好的Model，其中User2Group就是映射一张关系表，大家可以看到我在User里面定义了一个groups属性，那么我在代码中就可以如下获取某个用户，他到底是哪几个用户组的：

user = User.objects.get(pk=userid)
groups = user.groups.order_by("-groupName")

这里我只是简单的描述了一个多对多关系的使用，对于一个普通的用户，只要稍微有点py的基础知识，要掌握django并不难。
至于django的模板，我觉得也比较精简，很适合于快速开发，通俗易懂，易于上手，并且提供了很简单的定制和扩展方式，简单到你只需要写一个函数，就能自定义一个模板使用的filter。
对于django的url体系，采用了一套很精简的方案，就是通过自定义的正则url表达式，来影射与其对应的操作函数，并通过在正则表达式中使用命名参数，来向函数传递参数，比如下面的url定义：

urlpatterns = patterns('',
    (r'^user/(?P<id>\d+)/$', 'mysite.user.views.detail'),
}

这样的url定义意味着你可以通过诸如：http://localhost/user/23/的形式访问一个用户的信息。
然后定义如下一个函数：

def detail(request, id):
    user = User.objects.get(pk=id)
    groups = user.groups.order_by("-groupName")
    return render_to_response("user_detail.html", {"user":user, "groups":groups})

在上面的函数中,id就是通过url传过来的命名参数,函数获取信息后，将user和groups信息交给模板user_detail.html进行数据渲染后返回客户端。
整个过程基本就是这样。我观察过，一个普通的java程序员，从不懂python和django，在没有任何第三者予以帮助的情况下，如果能够流畅的阅读英语，一般一个星期左右，就能基本掌握基于django的简单的web应用开发。

此外我提几个与django框架无关的概念，但是在基于django开发的过程中，很有帮助，一个就是python内置的decorator的使用，可以实现很多的横向功能，比如用户权限验证，用户日志等等，而这种模式的直接好处就是实现对已有代码的最小化的侵入。另外一个就是python作为动态语言的基本特性之一，就是在py的运行环境中，任何东西都是对象，都是可以被动态的获取其属性的，包括你定义的函数，类，类的方法等等。还有很多，一时无从说起，只能以......

看贴之余，信笔涂鸦，其中代码并无测试，仅供参考。

django的URL是非常灵活的.楼主想URL 0配置的愿望可以理解,但是其实不是所有URL都能够合情合理地0配置,Django就允许你用很酷的方式来映射你的URL.当然你想Restful的URL映射,社区里是有很多这样的开源模块.

django的ORM我也是暴喜欢,admin太Cool了,特别是1.0支持inlineAdmin后,觉得admin可以做到的事情太多了.喜欢.

这种方式能否再进一步,就是正则表达式中包含method的信息,这样我就可以指定执行views中的哪个函数了,比如说
http://localhost/user/23/edit/就表示执行views中的edit方法,虽然看上去比较怪异,不过要比加methodName这种方式好多了,虽然不能restful,那url看起来比正文中看起来好了很多.


这个我想式django一大优势之一,入门确实很简单,不过不清楚django为什么没有在国内有运用起来,只有很少的网站在使用django.

事实上,完成整个例子,这个例子中还包括验证码,文件上传等,我只用了周末2天和周一到周五每天1个小时.这么好的东西为啥用的人不多呢?

之前我内心曾激烈斗争过,到底是学ror,还是django,斗争了相当长一段时间之后,我还是选择了django.