VB.net 2010 视频教程 VB.net 2010 视频教程 python基础视频教程
SQL Server 2008 视频教程 c#入门经典教程 Visual Basic从门到精通视频教程
当前位置:
首页 > 编程开发 > python爬虫 >

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

本站最新发布   Python从入门到精通|Python基础教程
试听地址  https://www.xin3721.com/eschool/pythonxin3721/


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

1
2
3
4
5
6
7
8
9
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，增强抽象级别。

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

相关教程