Django开发者七个常犯错误

  • 2019年10月26日 16:14
  • teddy
  • 242阅读
  • 0评论

耗时开始 2019-10-26 11:39:54 - 2019-10-26 12:01:28 2019-10-26 14:22:19 - 2019-10-26 15:11:09 耗时结束

Django是一个强大的web框架,与强大功能伴随的还有相应的义务。在本文中, 我们会介绍一些常见的错误,这些错误有时连中级的Django开发者也会犯,而且 大部分成功的Django项目也早晚会碰到这些问题。

重新开发轮子(Reinventing the wheel)

Django不仅自带了很多的功能,在第三方库中功能则更多。在写代码前, 可以试着先用google查找下你要解决的问题,很可能已经有现成的解决方案了。

你也可以使用在线的Django项目目录,在这里有超过3200个的项目。下面列 出几个有趣的项目:

提示:本人强烈推荐用cookiecutter-django来创建Django项目,这样自带自定 义用户模型,通过django-allauth进行注册管理,通过Anymail发送邮件,还有许多与 安全和部署相关的默认设置。

庞大的程序结构

Django的松耦合的框架,并不需要你用一些特殊的方法来构建网络应用。中级Django 开发者有一套标准的做法。

Django应用的基础是Django Project,由多个app构成。Django app是一个自我包含的 包,必须只做一件事。比如,博客、成员管理或者事件日历等。

Django的app可包含Python的模块,Django自己的模块(views,URLs,forms等), 静态文件,数据库迁移,管理命令,单元测试等等。你必须将项目分成小的、可重用 的简单逻辑。

\ecommerce_project      <= This is your Django project
    \cart               <= This is a Django cart app
    \checkout           <= This is a Django checkout app
    \products           <= This is a Django products app
    db.sqlite3          <= Your project database
    manage.py           <= Django project management utility

使用上面的结构,相关的功能放在一起,你和团队成员可以将项目看得更清楚。基于 此,你可以将应用导出到另一个项目,重新使用,或者发布到PyPi上作为一个开源的 模块。

写臃肿的表示层(template)和太简单的模型

Django的架构可以描述为Model-Template-View(MTV)或者Model-View-Template(MVT)

模型通常是所有业务逻辑实现的地方,被定义在models.py文件,放在应用目录下。 还包含将结果传递到视图和模板的数据库查询。

视图则包含与用户交互的代码,如用户表单提交、处理数据查询结果以便传递给模板。 被定义在views.py文件。

如果你没有将应用逻辑写在模型里面,然后使用视图,这意味着你将代码写在了基于 视图的模型。这就造成视图过于臃肿,模型则过于“苗条”。实际是模型必须臃肿而视图 必须苗条。

你还可以借用custom managers的力。比如,一个自定义管理器可以提供with_counts()方法, 该方法返回一个OpinionPoll对象集合,每个对象有包含额外的通过聚合查询得到 的num_responses属性。 要想了解更多的用法,可以参考UserManager

每个视图中包含太多的查询,或者查询没有优化

Django的ORM经常因查询太多或没有优化查询而被批评。但是,在其他使用ORM的 框架也存在该问题。

真实的问题是我们经常忽略性能表现和所需的资源。一旦你能找到瓶颈所在,你将 可以选择正确的方法来描述。有许多事你可以做,通常包括以下:

  • 修改 plain-broken的ORM查询(hello prefetching)
  • 微调和优化ORM查询
  • 在正确的地方添加缓存
  • 提供更多的资源

django-debug-toolbar是个很好的调试工具,可以用来跟踪SQL查询 的性能问题,请求,模板,缓存等。 这个小的工具可以帮助你快速发现问题,本人强烈推荐。

多余的模型列

由于查询不能通过计算列进行,添加一列又很简单,只要"make migrations"就行, 很多开发者或多或少都会以这样那样的方式添加重复的数据。

很快,你将会碰到is_motorcycle == Truewheel_count == 4,你自己也不知道 要信任哪一列。

使用Django,你可以使用@property装饰器重写类似上述不一致的属性。然而, 由于ORM允许你通过将列作为属性,相反的则行不通,你必须自己重写每个查询。

没有为模型添加索引

甚至中级的Django开发者也会忘记索引。请记得为模型添加索引!但是,不要 为所有的列都添加索引,不然会让插入、更新、删除变得很慢。一般的原则是, 将需要过滤或者join的列添加索引。分析查询数据集来决定哪里需要索引。

不一致的数据验证

Django的模型可以关联一个或多个表单,用来创建或更新模型实例。表单有许多 默认的行为,特别是验证,这是通过模型的属性控制的。实际上,很多模型的属性 仅仅是为了控制表单的默认行为。

很多Django开发者忘了不止通过表单可以更改模型,也忘了跟踪哪个限制是在哪里。 Non-null?是在模型上的。在列上定义choice类型,列出有什么值?这时在表单上 的行为。唯一的?是在模型上。等等。

这些不一致的验证导致了差的用户体验:表单,基于存在的数据预先生成的内容, 这个是不能被提交的,应为数据是无效的。

总结

Django是一门快速构建软件的技艺。然而,当急着添加新的功能时很容易忘记一些 事及看不清具体的目的。在本文,我们了解了Django开发者常犯的错误,就能更 好的避开。

来源

7 Common Mistakes That Django Developers Make

    0人参与|共 0 条评论
    还没有评论呢