今天终于在javaeye开通了Django Cookbook的专栏（），马上发一篇Django相关技巧的文章来热热身吧。

Django的用户模型：

Django和其他很多Web框架不同的一点就是它自带了一个现成的User Model，因为Web开发中99%会涉及到用户这个概念，自带一个User Model，不但解决了每次开发一个新的项目的时候，都不得不为新建一个用户表所做的重复工作。而且最大的好处是由于Django Model特有的处理方式，只有通过django.contrib.auth.models 导入 User Model，那么不管你是来自哪个app，各个app之间引用的都是同一个User Model，而那些域通过ForeignKey，ManyToManyField，OneToOneField指向User Model后在数据库中所产生的真正外键都是参照 auth_user 表的 id，这对于很多相互独立但都需要一个用户模型的app来说是不可缺少的机制，因为如果django不内置User Model，那个每个app就得各自为政，独立定义User Model，最后的结果就是当想把这些app组合起来使用的时候，由于User Model不统一而得花大量时间来修改这些app的User Model相关的代码。

这个优点表现最明显的例子就是 Pinax Project （），这是个将大量开源app组合起来经过简单配置组装而成的一个SNS工程。

Django用户模型的问题：

虽然 Django 自带了User Model方便了很多app的组合，但是由于每个app肯定都需要再增加一些信息到用户模型中，而Django自带的User Model 中所定义的field都是一些很常规的信息，肯定无法满足app本身的需求。为此就需要增加一个profile，放用户额外的信息。这主要由以下几种方式：

1、Django官方指导的方式：

见文档

大概过程就是这样：定义一个Profile Model，里面包含一个unique=True的ForeignKey ，在settings.py 添加一个选项 AUTH_PROFILE_MODULE 指向该Profile Model，那么自带User Model的实例就可以通过get_profile()来获取相应的profile的信息了，这个方法虽然看上去很方便，但是有一个很明显的缺点就是profile是在一张另外的表中，虽然get_profile()缓存了第一次取的的profile的结果，但是每个http请求之间都得为此做一个查询，当用户数量很多的时候，对性能的影响就比较大了。另外一个问题是当需要定义像friends这样的指向 'self' 的 ManyToManyField时该怎么办？定义在profile中就显得很不合理了，一个用户和另一个用户做朋友，而不是和ta的profile做朋友，更何况定义在profile中的话，当做friends的反向查询的时候，取得的queryset是profiles，这时候又想取得这些profile指向的user的信息的时候就得再做大量查询了。

2、修改Django的源代码直接在User Model上加字段了：

这种方法很直接效果也很明显，如果用得像是1.0.2-final这样的最终发布版，并且以后也不打算更新Django版本的话这样也是可以的。但是如果是用SVN development版的话，这种修改源码的方式就显得有点暴力了。

3、直接舍弃Django的User Model，自己重头定义一个User Model，包括自己管理auth，写auth backends：

我见过几个项目都是这样做的了，虽然通过继承原有User Model，ModelBackend等类，可以只需要写很少的代码就可以实现，这种方式其实修改Django源码没什么大的区别，都是减少了一张profile表，只不过扩展后的User Model一个是放在Django源码里，一个是放在自己的源码里，而且这种方式比修改源码更糟的是，这破坏了开头提到的与其他app组合使用的可能性。

不修改django源码也不增加profile表的扩展用户模型：

上面提到的各种方式主要都是围绕修改django源码和增加一张profile表之间的权衡利弊展开。那么有没有一种两全其美的方式呢，既不修改源码，也不增加profile表。答案是有的，而且在很早的django版本中，这甚至是很常用的方式，只是后来django修改了Model部分的源码，阻止了这种方式，因为这看上去太magic了。

以前的django model中的inner Meta中可以定义一个 replaces_module 的参数，用来指定你想将该Model替换另外一个Model，看上去很奇怪也很神奇，但是管理起来也显得很混乱，所以最后这个特性被取消了。

虽然上面这种方式被阻止了，但是还是可以通过其他方式动态的修改User Model类，说了这么多，还是直接看源码来的更清楚些吧：

# -*- coding: utf-8 -*-from django.db import modelsfrom django.contrib.auth.models import Userfrom django.contrib.auth.admin import UserAdminimport datetimeclass ProfileBase(type):    def __new__(cls, name, bases, attrs):        module = attrs.pop('__module__')        parents = [b for b in bases if isinstance(b, ProfileBase)]        if parents:            fields = []            for obj_name, obj in attrs.items():                if isinstance(obj, models.Field): fields.append(obj_name)                User.add_to_class(obj_name, obj)            UserAdmin.fieldsets = list(UserAdmin.fieldsets)            UserAdmin.fieldsets.append((name, {'fields': fields}))        return super(ProfileBase, cls).__new__(cls, name, bases, attrs)        class Profile(object):    __metaclass__ = ProfileBaseclass MyProfile(Profile):    nickname = models.CharField(max_length = 255)    birthday = models.DateTimeField(null = True, blank = True)    city = models.CharField(max_length = 30, blank = True)    university = models.CharField(max_length = 255, blank = True)        def is_today_birthday(self):        return self.birthday.date() == datetime.date.today()

上面的代码中定义了一个ProfileBase的元类，然后定义了一个作为Profile基类的Profile类，并且它的元类为ProfileBase。

元类的作用简单来讲，就是创建其他类的类。也就是元类的实例是普通类，而普通类的实例就是普通的实例。

如果你不理解这些也没关系，只要知道，上面的代码中，当解释器看到你在定义一个Profile类的子类，而Profile类的元类是ProfileBase，所以MyProfilede的元类也是ProfileBase，也就是在定义任何Profile的子类的时候，它就会执行元类ProfileBase中的__new__中代码，并且将正在定义的类的（名字，基类，类属性）作为参数传递给__new__。

MyProfilede中的field采用了和普通Model相同的声明语法，所以这些field和那个自定义方法is_today_birthday会作为attrs中的属性传递过去，然后元类中将这些信息提取出来通过 User.add_to_class(obj_name, obj) 加入到User类中，add_to_class也是普通Model中定义field时采用的方式，因为普通Model也有一个元类在做相似的事情，只不过这里定义的这个元类专门往User Model中加东西。

在添加完这些field和自定义方法后，前面识别出哪些属性是field，然后加入到UserAdmin.fieldsets中，那样在admin中就可以和其他User fields 一起编辑这些新加的field了。

如果你有其他app也想往User Model中加field或方法，都只要通过子类Profile类，然后使用声明语法进行定义即可，所有其他工作都有元类帮你完成。

通过这种方式添加到User Model中的field和方法的效果就和直接修改Django User Model的源码一样，只不过现在这些修改不用再像修改源码这么暴力了，而且想添的时候随便可以添。

需要注意的地方：

1、以上元类的定义包括MyProfile的定义，最好就和普通Model一样，放在app的models.py文件中， 以便django可以方便的碰到这些定义，否则django没看到这些代码也就没效果了，而且放在其他地方非常容易引起导入的依赖问题。

2、如果你已经通过syncdb同步了数据库，再使用此方法扩展用户模型，那么Django虽然知道你定义了这些field，但是再次运行syncdb时，不会再为这些field自动创建数据库字段，因为django的syncdb只负责创建新表的字段。这与你已经定义了一个Model并运行syncdb，然后往那个Model上又加了fields是同一种情况。

最后，我将继续努力，认真写好这个Django Cookbook的专栏（），希望大家多多捧场，提点错误。

原文网址：