首页 > 代码库 > 建立一个更高级别的查询 API：正确使用Django ORM 的方式（转）
建立一个更高级别的查询 API：正确使用Django ORM 的方式（转）
add by zhj: 本文作者是DabApps公司的技术主管，作者认为在view中直接使用Django提供的ORM查询方法是不好的，我对此并不赞同，可能作者
写这篇文章是给Django的初学者看，所以在说明方法演进时有些罗嗦，至少方法1是没有必要说的。
本文介绍了如何给QuerySet类增加方法属性。作者写本文时，Django1.7还在开发中，没有发布。在Django1.7版本中提供了这个功能，
见https://docs.djangoproject.com/en/dev/releases/1.7/#calling-custom-queryset-methods-from-the-manager。另：我对译文有修改。
英文原文：http://www.dabapps.com/blog/higher-level-query-api-django-orm/
译文原文：http://www.oschina.net/translate/higher-level-query-api-django-orm
译者：Naixjs, fkkeee, 晴风晓月
摘要
在这篇文章里，我认为在view中直接使用Django的低级的ORM查询方法（如filter, order_by等）通常是反模式的。作为一种替代方式，我们需要在模型层建立
查询API，这在Django中做起来不是非常容易，但通过深入地了解ORM的内部，我将告诉你一些简捷的方式来达到这个目的。
概览
当编写Django应用程序时，我们已经习惯通过添加method到model中以此达到封装业务逻辑并隐藏实现细节。这种方法看起来是非常的自然，而且实际上它也用在
Django的内建应用中。
from django.contrib.auth.models import Useruser = User.objects.get(pk=5)user.set_password(‘super-sekrit‘)user.save()
这里的set_password就是一个定义在django.contrib.auth.models.User这个model中的方法，它隐藏了对密码进行哈希操作的具体实现。相应的代码看起来应该
是这样：
from django.contrib.auth.hashers import make_passwordclass User(models.Model): # fields go here.. def set_password(self, raw_password): self.password = make_password(raw_password)
这样做的好处是使代码更具可读性、重用性和健壮性。
我们已经在单独的例子中这样做了，下面将会把它用在获取数据库信息的例子中。
为了描述这个方法，我们使用了一个简单的app(todo list)来说明。注意：这是一个例子，因为很难用少量的代码展示一个真实的例子。
下面就是models.py文件:
from django.db import modelsPRIORITY_CHOICES = [(1, ‘High‘), (2, ‘Low‘)]class Todo(models.Model): content = models.CharField(max_length=100) is_done = models.BooleanField(default=False) owner = models.ForeignKey(‘auth.User‘) priority = models.IntegerField(choices=PRIORITY_CHOICES, default=1
想像一下，我们需要查询当前用户所有不完整的，高优先级的 Todos。这里是代码：
def dashboard(request): todos = Todo.objects.filter( owner=request.user ).filter( is_done=False ).filter( priority=1 ) return render(request, ‘todos/list.html‘, { ‘todos‘: todos, })
注意：这里可以写成request.user.todo_set.filter(is_done=False, priority=1)。但是记住这里只是一个实验。
为什么这样写不好呢？
首先，代码冗长。七行代码才能完成，正式的项目中，将会更加复杂。
其次，泄露实现细节。比如我们需要知道model中有一个名为is_done的布尔型字段，如果你将字段类型修改为有多个允许值的field，那这个代码就不能用了。
然后就是，意图不清晰，很难理解。
最后，使用中会有重复。例：你需要写一个management command，每周给每个用户发送他自己的todo list，这时候你就需要复制-粘贴着七行代码。这不符合
DRY（do not repeat yourself）
让我们总结一下：直接使用低等级的ORM代码是反模式的。
如何改进呢？
使用 Managers 和 QuerySets
首先，让我们先了解一下概念。
Django 有两个关系密切的与表级别操作相关的结构：managers 和 querysets
manager(django.db.models.manager.Manager的一个实例)被描述成 “为model提供查询数据库操作的接口”。Manager是通往表级功能的大门。每一个model
都有一个默认的manager，叫做objects。
Quesyset (django.db.models.query.QuerySet) 是“数据库中objects的集合”。本质上是一个lazy SELECT查询，也可以使用过滤，排序等（filtered,ordered），
来限制或者修改查询 到的数据。用它来创建或操纵 django.db.models.sql.query.Query实例，然后在数据库后台转换成SQL查询。
啊？你还不明白？
随着你慢慢深入的了解ORM，你就会明白Manager和QuerySet之间的区别了。
人们会被所熟知的Manager接口搞糊涂，因为他并不是看上去那样。
Manager接口就是个谎言。
QuerySet方法是可链式调用的。每一次调用QuerySet的方法（如:filter）都会返回一个复制的queryset等待下一次的调用。这也是Django ORM 流畅之美的一部分。
QuerySet 的所有方法需要在Manager中要重新实现，从而通过model.objects也可以实现链式调用。这些方法在Manager中只是QuerySet中对应方法的代理，通过
self.get_query_set()，如下
class Manager(object): # SNIP some housekeeping stuff.. def get_query_set(self): return QuerySet(self.model, using=self._db) def all(self): return self.get_query_set() def count(self): return self.get_query_set().count() def filter(self, *args, **kwargs): return self.get_query_set().filter(*args, **kwargs) # and so on for 100+ lines...
让我们立刻回到todo list ，解决query接口的问题。Django推荐的方法是自定义Manager子类，并加在models中。
class IncompleteTodoManager(models.Manager): def get_query_set(self): return super(TodoManager, self).get_query_set().filter(is_done=False)class HighPriorityTodoManager(models.Manager): def get_query_set(self): return super(TodoManager, self).get_query_set().filter(priority=1)class Todo(models.Model): content = models.CharField(max_length=100) # other fields go here.. objects = models.Manager() # the default manager # attach our custom managers: incomplete = models.IncompleteTodoManager() high_priority = models.HighPriorityTodoManager()
你也可以在model中增加多个managers，或者重新定义objects，也可以维持单个的manager，增加自定义方法。
下面让我们实验一下这几种方法：
方法1：多managers
class IncompleteTodoManager(models.Manager): def get_query_set(self): return super(TodoManager, self).get_query_set().filter(is_done=False)class HighPriorityTodoManager(models.Manager): def get_query_set(self): return super(TodoManager, self).get_query_set().filter(priority=1)class Todo(models.Model): content = models.CharField(max_length=100) # other fields go here.. objects = models.Manager() # the default manager # attach our custom managers: incomplete = models.IncompleteTodoManager() high_priority = models.HighPriorityTodoManager()
我们的API看起来是这样：
>>> Todo.incomplete.all()>>> Todo.high_priority.all()这个方法有几个问题。
第一，这种实现方式比较啰嗦。你要为每一个自定义查询定义一个manager。
第二，这将会弄乱你的命名空间。因为Django开发者习惯把Model.objects看做表的入口，而这种方法会破坏这个规则。
第 三，不可链式调用。还是要用低等级的ORM代码实现：Todo.incomplete.filter(priority=1) 或Todo.high_priority.filter(is_done=False)
综上，使用多managers的方法，不是最优选择。
方法2: Manager 方法
现在，我们试下其他Django允许的方法：在单个自定义Manager中的多个方法
class TodoManager(models.Manager): def incomplete(self): return self.filter(is_done=False) def high_priority(self): return self.filter(priority=1)class Todo(models.Model): content = models.CharField(max_length=100) # other fields go here.. objects = TodoManager()
我们的API 现在看起来是这样：
>>> Todo.objects.incomplete()>>> Todo.objects.high_priority()这个方法显然更好。它没有太多累赘（只有一个Manager类）并且可以很方便地添加更多的方法。
不过仍然不能链式调用自定义方法，因为Todo.objects.incomplete() 和Todo.objects.high_priority()返回的都是Django QuerySet类的实例，所以我们
无法使用Todo.objects.incomplete().high_priority() 。
方法3：自定义QuerySet
现在我们已进入Django尚未开发的领域，Django文档中找不到这些内容。
class TodoQuerySet(models.query.QuerySet): def incomplete(self): return self.filter(is_done=False) def high_priority(self): return self.filter(priority=1)class TodoManager(models.Manager): def get_query_set(self): return TodoQuerySet(self.model, using=self._db)class Todo(models.Model): content = models.CharField(max_length=100) # other fields go here.. objects = TodoManager()
我们从以下调用的视图代码中可以看出端倪：
>>> Todo.objects.get_query_set().incomplete()>>> Todo.objects.get_query_set().high_priority()>>> # (or)>>> Todo.objects.all().incomplete()>>> Todo.objects.all().high_priority()
差不多完成了！这并有比第2个方法多多少累赘，得到方法2同样的好处，和额外的效果（来点鼓声吧...），它终于可链式查询了！
>>> Todo.objects.all().incomplete().high_priority()
然而它还不够完美。这个自定义的Manager仅仅是一个样板而已，而且 all() 还有瑕疵，在使用时不好把握，而更重要的是不兼容，它让我们的代码看起来有点怪异。
方法3a：复制Django，代理做所有事
我们简单地在Manager中重新定义所有QuerySet方法
QuerySet：
class TodoQuerySet(models.query.QuerySet): def incomplete(self): return self.filter(is_done=False) def high_priority(self): return self.filter(priority=1)class TodoManager(models.Manager): def get_query_set(self): return TodoQuerySet(self.model, using=self._db) def incomplete(self): return self.get_query_set().incomplete() def high_priority(self): return self.get_query_set().high_priority()
这个能更好地提供我们想要的API：
>>> Todo.objects.incomplete().high_priority() # yay!
但代码冗余、且不符合DRY，每次你新增一个文件到QuerySet，或是更改现有的方法标记，你必须记住在你的Manager中做相同的更改，否则它可能不会正常工作。
方法3b： django-model-utils
Python 是一种动态语言，我们可以做到DRY吗？答案是肯定的，要通过一个名叫Django-model-utils的第三方应用帮忙。运行 pip install django-model-utils ，
然后……
from model_utils.managers import PassThroughManagerclass TodoQuerySet(models.query.QuerySet): def incomplete(self): return self.filter(is_done=False) def high_priority(self): return self.filter(priority=1)class Todo(models.Model): content = models.CharField(max_length=100) # other fields go here.. objects = PassThroughManager.for_queryset_class(TodoQuerySet)()
这要好多了。我们只是定义QuerySet子类，然后通过django-model-utils提供的PassThroughManager类附加这个自定义QuerySet子类到我们的model中。
PassThroughManager 是由__getattr__ 实现的，当调用objects不存在的方法时，它会自动代理它们到QuerySet。这里需要小心一点，检查确认我们没有在一
些特性中没有无限递归（这是我为什么推荐使用django-model-utils，而不是自己手工写）。
做这些有什么帮助？
记得之前定义的view吗？
def dashboard(request): todos = Todo.objects.filter( owner=request.user ).filter( is_done=False ).filter( priority=1 ) return render(request, ‘todos/list.html‘, { ‘todos‘: todos, })
加点小改动，它看起来是这样：
def dashboard(request): todos = Todo.objects.for_user( request.user ).incomplete().high_priority() return render(request, ‘todos/list.html‘, { ‘todos‘: todos, })
希望你也能同意第二个版本比第一个更简便，清晰并且更有可读性。
Django能帮忙么？
让这整个事情更容易的方法，已经在django开发邮件列表中讨论过，下面是Zachary Voase的建议：
class TodoManager(models.Manager): @models.querymethod def incomplete(query): return query.filter(is_done=False)
通过这个简单的装饰方法的定义，让Manager和QuerySet都能使不可用的方法神奇地变为可用。
我个人并不完全赞同使用装饰器的方法。它略过了详细的信息，感觉有点“嘻哈”。我感觉好的方法是增加一个QuerSet子类（而不是Manager子类）。
或者我们更进一步思考。退回到在争议中重新审视Django的API设计决定时，也许我们能得到真实更深的改进。可以消除Managers和QuerySet的区别吗
（或者至少使这个区别更明显）？
我很确信，不管以前是否曾经有过这么大的重构工作，这个功能必然要在Django 2.0 甚至更后的版本中。
因此，简单概括一下：
在视图和其他高级应用中使用源生的ORM查询代码不是很好的主意。而是用django-model-utils中的PassThroughManager将我们新加的自定义QuerySet API
加进你的模型中，这能给你以下好处：
啰嗦代码少，并且更健壮。
增加DRY，增强抽象级别。
将所属的业务逻辑推送至模型层实现。
感谢阅读。