建立一个更高级别的查询 API：正确使用Django ORM 的方式(6)

当前位置:

首页 > Python基础教程 >

建立一个更高级别的查询 API：正确使用Django ORM 的方式(6)

加点小改动，我们让它看起来象这样：

						def dashboard(request):

						    todos= Todo.objects.for_user(

						        request.user

						    ).incomplete().high_priority()

						    return render(request,'todos/list.html', {

						        'todos': todos,

						    })

希望你也能同意第二个版本比第一个更简便，清晰并且更有可读性。

Django能帮忙么？

让这整个事情更容易的方法，已经在django开发邮件列表中讨论过，并且得到一个相关票据(译注：associated ticket叫啥名更好？)。Zachary Voase则建议如下：

1

2

3

4

5

						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，增强抽象级别。

将所属的业务逻辑推送至对应的域模型层。

栏目列表