建立一个更高级别的查询 API：正确使用Django ORM 的方式
摘要
在这篇文章里，我将以反模式的角度来直接讨论Django的低级ORM查询方法的使用。作为一种替代方式，我们需要在包含业务逻辑的模型层建立与特定领域相关的查询API，这些在Django中做起来不是非常容易，但通过深入地了解ORM的内容原理，我将告诉你一些简捷的方式来达到这个目的。
概览
当编写Django应用程序时，我们已经习惯通过添加方法到模型里以此达到封装业务逻辑并隐藏实现细节。这种方法看起来是非常的自然，而且实际上它也用在Django的内建应用中。
| 1234 | >>> from django.contrib.auth.models import User>>> user = User.objects.get(pk=5)>>> user.set_password(\’super-sekrit\’)>>> user.save() |
这里的set_password就是一个定义在django.contrib.auth.models.User模型中的方法，它隐藏了对密码进行哈希操作的具体实现。相应的代码看起来应该是这样：
| 12345678 | from django.contrib.auth.hashers import make_password class User(models.Model): # fields go here.. def set_password(self, raw_password): self.password = make_password(raw_password) |
我们正在使用Django，建立一个特定领域的顶部通用接口，低等级的ORM工具。在此基础上，增加抽象等级，减少交互代码。这样做的好处是使代码更具可读性、重用性和健壮性。
我们已经在单独的例子中这样做了，下面将会把它用在获取数据库信息的例子中。
为了描述这个方法，我们使用了一个简单的app(todo list)来说明。
注意：这是一个例子。因为很难用少量的代码展示一个真实的例子。不要过多的关心todo list继承他自己，而要把重点放在如何让这个方法运行。
下面就是models.py文件:
| 123456789 | from django.db import models PRIORITY_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 |
想像一下，我们将要传递这些数据，建立一个view，来为当前用户展示不完整的，高优先级的 Todos。这里是代码：
| 12345678910111213 | 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)。但是这里只是一个实验。
为什么这样写不好呢？
首先，代码冗长。七行代码才能完成，正式的项目中，将会更加复杂。
其次，泄露实现细节。比如代码中的is_done是BooleanField，如果改变了他的类型，代码就不能用了。
然后就是，意图不清晰，很难理解。
最后，使用中会有重复。例：你需要写一行命令，通过cron，每周发送给所有用户一个todo list，这时候你就需要复制-粘贴着七行代码。这不符合DRY（do not repeat yourself）
让我们大胆的猜测一下：直接使用低等级的ORM代码是反模式的。
如何改进呢？
使用 Managers 和 QuerySets
首先，让我们先了解一下概念。
Django 有两个关系密切的与表级别操作相关的构图：managers 和 querysets
manager(django.db.models.manager.Manager的一个实例)被描述成 “通过查询数据库提供给Django的插件”。Manager是表级别功能的通往ORM大门。每一个model都有一个默认的manager，叫做objects。
Quesyset
(django.db.models.query.QuerySet) 是“数据库中objects的集合”。本质上是一个SELECT查询，也可以使用过滤，排序等（filtered,ordered），来限制或者修改查询到的数据。用来
创建或操纵
django.db.models.sql.query.Query实例，然后通过数据库后端在真正的SQL中查询。
啊？你还不明白？
随着你慢慢深入的了解ORM，你就会明白Manager和QuerySet之间的区别了。
人们会被所熟知的Manager接口搞糊涂，因为他并不是看上去那样。
Manager接口就是个谎言。
QuerySet方法是可链接的。每一次调用QuerySet的方法（如:filter）都会返回一个复制的queryset等待下一次的调用。这也是Django ORM 流畅之美的一部分。
但是当Model.objects 是一个 Manager时，就出现问题了。我们需要调用objects作为开始，然后链接到结果的QuerySet上去。
那么Django又是如何解决呢？
接口的谎言由此暴露，所有的QuerySet 方法基于Manager。在这个方法中，通过self.get_query_set()的代理，重新创建一个QuerySet。
| 1234567891011121314151617 | 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() 建立与特定领域相关的查询API，这些在Django中做起来不是非常容易，但通过深入地了解ORM的内容原理，我将告诉你一些简捷的方式来达到这个目的。
概览 当编写Django应用程序时，我们已经习惯通过添加方法到模型里以此达到封装业务逻辑并隐藏实现细节。这种方法看起来是非常的自然，而且实际上它也用在Django的内建应用中。
这里的set_password就是一个定义在django.contrib.auth.models.User模型中的方法，它隐藏了对密码进行哈希操作的具体实现。相应的代码看起来应该是这样：
我们正在使用Django，建立一个特定领域的顶部通用接口，低等级的ORM工具。在此基础上，增加抽象等级，减少交互代码。这样做的好处是使代码更具可读性、重用性和健壮性。 我们已经在单独的例子中这样做了，下面将会把它用在获取数据库信息的例子中。 为了描述这个方法，我们使用了一个简单的app(todo list)来说明。 注意：这是一个例子。因为很难用少量的代码展示一个真实的例子。不要过多的关心todo list继承他自己，而要把重点放在如何让这个方法运行。 下面就是models.py文件:
想像一下，我们将要传递这些数据，建立一个view，来为当前用户展示不完整的，高优先级的 Todos。这里是代码：
注意：这里可以写成request.user.todo_set.filter(is_done=False, priority=1)。但是这里只是一个实验。 为什么这样写不好呢？ 首先，代码冗长。七行代码才能完成，正式的项目中，将会更加复杂。 其次，泄露实现细节。比如代码中的is_done是BooleanField，如果改变了他的类型，代码就不能用了。 然后就是，意图不清晰，很难理解。 最后，使用中会有重复。例：你需要写一行命令，通过cron，每周发送给所有用户一个todo list，这时候你就需要复制-粘贴着七行代码。这不符合DRY（do not repeat yourself） 让我们大胆的猜测一下：直接使用低等级的ORM代码是反模式的。 如何改进呢？ 使用 Managers 和 QuerySets 首先，让我们先了解一下概念。 Django 有两个关系密切的与表级别操作相关的构图：managers 和 querysets manager(django.db.models.manager.Manager的一个实例)被描述成 “通过查询数据库提供给Django的插件”。Manager是表级别功能的通往ORM大门。每一个model都有一个默认的manager，叫做objects。 Quesyset 啊？你还不明白？ 随着你慢慢深入的了解ORM，你就会明白Manager和QuerySet之间的区别了。 人们会被所熟知的Manager接口搞糊涂，因为他并不是看上去那样。 Manager接口就是个谎言。 QuerySet方法是可链接的。每一次调用QuerySet的方法（如:filter）都会返回一个复制的queryset等待下一次的调用。这也是Django ORM 流畅之美的一部分。 但是当Model.objects 是一个 Manager时，就出现问题了。我们需要调用objects作为开始，然后链接到结果的QuerySet上去。 那么Django又是如何解决呢？ 接口的谎言由此暴露，所有的QuerySet 方法基于Manager。在这个方法中，通过self.get_query_set()的代理，重新创建一个QuerySet。
|