【评】Tips for Building High-Quality Django Apps at Scale

内容简介：【评】Tips for Building High-Quality Django Apps at Scale

首发于小社群(码农悟凡公众号底部菜单可进)

原文地址： https://blog.doordash.com/tips-for-building-high-quality-django-apps-at-scale-a5a25917b2b5

整篇文章基本都是在讲Model层的东西，对于Django的应用，Model至关重要。

1. 关于项目结构的部分，我怀疑这哥们是写错了，现在Django创建完app就是他建议的那种。

2. 明确Model对应的表明，这个明确些确实会好很多，尤其是一个Model在不同的app中迁移的时候，如果不注意，你可能得查半天关于表不存在的问题。

3. 避免GenericForeignKey，之前有段时间我们也用过，但是最大的问题是，这样做会把Model耦合到表里面。不如自己实现来的方便。

4. 关于migrations，个人感觉主要是开发环境方便，生成环境你还用这个？那估计是疯了。

5. 合并migrations，这个建议不错，一段时间后重新生成migrations。

6. 减少migration冲突，这个没怎么遇到，不评论。

7. 避免Model过肥，数据层就应该干数据层的活，别掺杂业务到里面，会很难维护。

8. 谨慎使用Signals，这个东西是解耦合的很好的方式，但是不能滥用，太多的signal，自己找起来都困难，更别去跟踪执行过程和结果了。

9. 避免使用ORM的接口作为主要依赖，这点很奇怪，再封装出来一层没啥意义，除非明确的知道以后要替换ORM。

10. 不要CacheDjangoModel，这点主要是针对对象的缓存，在Django中，用自带的缓存，可以直接缓存一个对象实例进去（pickle类的东西）。the5fire也受过这个苦，变更Model后，重新部署项目，挂了。最终还是清理了缓存才ok的。最佳建议是只缓存数据。

关于第10点再补充一句，最新的PyCon2017上，instagram也遇到了类似的坑，不同 Python 版本之间pickle之后缓存相互不兼容。在生产环境中这是一个很危险的操作。开发环境测试，一切ok。谁会想到缓存上会有问题，毕竟缓存是随时可以清的。

欢迎讨论。

以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

• 【评】Tips for Building High-Quality Django Apps at Scale
• 【评】Tips for Building High-Quality Django Apps at Scale

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。