py变得巨大，分解它的最佳方法是什么？

Question

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

我觉得这是错误的路。我觉得将逻辑放在模型之外，只是为了使文件保持较小是一个坏主意。如果逻辑在模型中最好，那么无论文件大小如何，它都应该去做。

那么，是否有一种简单的使用方法包括？在PHP语中，我想向主管求婚，我们只是 models.py 包括（）来自其他地方的模型类。从概念上讲，这将允许模型具有我们想要的所有逻辑，但通过增加文件数量（这会导致更少的修订控制问题（例如冲突等），请保持文件大小。

因此，是否有一种简单的方法可以从型号删除模型类。或者，是否有完全不同而优雅的解决方案来解决“大”模型的一般问题？任何输入都将不胜感激。

Answer 1

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

在每个大型应用程序中，许多小型应用程序都在努力自由。

如果你的 models.py 感觉很大，你做得太多了。停止。放松。分解。

查找较小的，可能可重复使用的小型应用程序组件或零件。你不必 实际上 重复使用它们。只需将它们视为可能重复使用的。

考虑您的升级路径和分解应用程序，您可能想替换一天。你不必 实际上 替换它们，但您可以将它们视为编程的独立“模块”，将来可能会被更酷的东西替换。

我们有大约十几个应用程序 model.py 不超过400行代码。他们都非常专注于少于六个离散类定义。 （这些不是硬限制，它们是关于我们的代码的观察。）

我们很早就分解。

Answer 2

模型类包含在模型上操作的方法是很自然的。如果我有书籍模型， book.get_noun_count(), ，这就是它所属的地方 - 我不想写”get_noun_count(book)“除非该方法实际上属于其他一些软件包。get_amazon_product_id(book)".)

当Django的文档建议将模型放入一个文件中时，我畏缩了一下，从一开始就花了几分钟才能弄清楚如何将其分成适当的子包。

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

__init__.py 好像：

from .book import Book

因此，我仍然可以写“从site.models导入书”。

---

以下仅是Django 1.7之前的版本所需的，请参见 https://code.djangoproject.com/ticket/3591

唯一的技巧是，由于Django中的一个错误，您需要明确设置每个模型的应用程序：它假设应用程序名称是模型路径中的第三到较长条目。 “ site.models.book”导致“站点”，这是正确的； “ site.models.book.book”使其认为应用程序名称是“模型”。这是Django的一个非常讨厌的黑客。它可能应搜索已安装应用程序的列表中的前缀匹配。

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

您可能可以使用基类或元类来概括这一点，但我还没有为此而烦恼。

Answer 3

我无法理解您可能遇到的许多可能的问题。以下是一些有答案的可能性：

• 同一文件中的多个模型

  将它们放入单独的文件中。如果有依赖性，请使用导入来拉动其他模型。

• 多余的逻辑 /实用程序在型号中的功能。

  将额外的逻辑放入单独的文件中。

• 从数据库中选择某些模型实例的静态方法

  创建一个新的 经理 在单独的文件中。

• 方法显然与模型有关

  保存，__unicode__和get_absolute_url就是示例。