一尘不染

models.py越来越大,最好的分解方法是什么?

django

主管的指示:“我要避免在其中添加任何逻辑models.py。从现在开始,让我们将其用作访问数据库的类,并将所有逻辑保留在使用模型类或包装它们的外部类中。”

我觉得这是错误的方法。我觉得将逻辑排除在模型之外只是为了减小文件大小是一个坏主意。如果逻辑在模型中是最好的,那么无论文件大小如何,它实际上都是应该去的地方。

那么有没有一种简单的方法可以只使用include?用PHP讲,我想向主管建议,我们只是models.py从其他地方获得了include()模型类。从概念上讲,这将使模型具有我们想要的所有逻辑,但可以通过增加文件数量来减小文件大小(从而减少诸如冲突等的版本控制问题)。

因此,有没有一种简单的方法可以从models.py文件中删除模型类,但仍然可以使模型与所有Django工具一起使用?或者,对于“大” models.py文件的一般问题,是否有完全不同但优雅的解决方案?任何输入将不胜感激。


阅读 392

收藏
2020-03-29

共2个答案

一尘不染

Django旨在让你构建许多小型应用程序,而不是一个大型应用程序。

在每个大型应用程序中,都有许多免费的小型应用程序。

如果你models.py觉得自己很大,那你就做得太多了。停止。放松。分解。

查找较小的,可能可重用的小型应用程序组件或组件。你不必实际重用它们。只是将它们视为潜在可重用的对象。

考虑你的升级路径并分解你可能需要替换的应用程序。你不必实际替换它们,但是你可以将它们视为独立的编程“模块”,将来可能会替换为更酷的东西。

我们大约有十二个应用程序,每个应用程序model.py最多不超过400行代码。它们都集中在少于大约六个离散类定义上。(这些不是硬性限制,它们是对我们代码的观察。)

我们会早期分解,而且经常分解。

2020-03-29
一尘不染

模型类很自然地包含对模型进行操作的方法。如果我有一个带有方法的Book模型,book.get_noun_count()那就是它的所属位置-我不想写“ get_noun_count(book)”,除非该方法实际上本质上属于其他软件包。(例如,如果我有一个用于通过“ get_amazon_product_id(book)” 访问Amazon API的程序包,则可能会。)

当Django的文档建议将模型放在一个文件中时,我感到很吃惊,从一开始我就花了几分钟时间弄清楚如何将其拆分为适当的子包。

site/models/__init__.py
site/models/book.py

__init__.py 好像:

from .book import Book

所以我仍然可以写“ from site.models import Book”。

只有Django 1.7之前的版本才需要以下内容,请参阅 https://code.djangoproject.com/ticket/3591

唯一的技巧是,由于Django中的一个错误,你需要显式设置每个模型的应用程序:它假定应用程序名称是模型路径中倒数第二个条目。“ site.models.Book”的结果为“ site”,这是正确的;“ site.models.book.Book”使其认为应用程序名称为“ models”。对于Django而言,这是一个非常讨厌的技巧;它可能应该在已安装的应用程序列表中搜索前缀匹配项。

class Book(models.Model):
    class Meta: app_label = "site"

你可能可以使用基类或元类对此进行概括,但是我还没有对此感到烦恼。

2020-03-29