主管的指示：“我要避免在其中添加任何逻辑models.py。从现在开始，让我们将其用作访问数据库的类，并将所有逻辑保留在使用模型类或包装它们的外部类中。”
我觉得这是错误的方法。我觉得将逻辑保持在模型之外只是为了减小文件大小是一个坏主意。如果模型中的逻辑最好，则无论文件大小如何，逻辑都是真正应该去的地方。
那么，有没有一种简单的方法可以只使用include？用PHP讲，我想向主管建议，我们只是models.py从其他地方获得了include（）模型类。从概念上讲，这将使模型具有我们想要的所有逻辑，但可以通过增加文件数量来减小文件大小（从而减少诸如冲突等的版本控制问题）。
因此，有没有一种简单的方法可以从models.py文件中删除模型类，但是仍然可以使模型与所有Django工具一起使用？或者，对于“大” models.py文件的一般问题，是否有完全不同但优雅的解决方案？任何输入将不胜感激。
Answers:
Django旨在让您构建许多小型应用程序，而不是一个大型应用程序。
在每个大型应用程序内部，都有许多免费的小型应用程序。
如果您models.py觉得自己很大，那您就做得太多了。停止。放松。分解。
查找较小的，可能可重用的小型应用程序组件或组件。您不必实际重用它们。只需将它们视为潜在可重用的对象。
考虑您的升级路径并分解您可能需要替换的应用程序。您不必实际替换它们，但是您可以将它们视为独立的编程“模块”，将来可能会替换为更酷的东西。
我们大约有十二个应用程序，每个应用程序model.py最多不超过400行代码。它们都集中在少于大约六个离散类定义上。（这些不是硬性限制，它们是对我们代码的观察。）
我们经常分解。
模型类很自然地包含对模型进行操作的方法。如果我有一个带有方法的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"您可能可以使用基类或元类对此进行概括，但是我还没有对此感到烦恼。