我的主管的指示：
“我想避免在models.py中添加任何逻辑。从现在开始，让我们将其用作访问数据库的类，并将所有逻辑保存在使用模型类的外部类中，或者将它们包装起来。”
我觉得这是错误的方式。我认为保持模型逻辑只是为了保持文件小是一个坏主意。如果逻辑在模型中是最好的，那么无论文件大小如何，它都应该去。
那么有一种简单的方法可以使用包含吗？在PHP中，我想向主管建议我们只有models.py include（）来自其他地方的模型类。从概念上讲，这将允许模型具有我们想要的所有逻辑，但通过增加文件数量来减少文件大小（这会导致较少的修订控制问题，如冲突等）。
那么，是否有一种从models.py文件中删除模型类的简单方法，但仍然可以使用所有Django工具的模型？或者，对于“大型”models.py文件的一般问题，是否存在完全不同但优雅的解决方案？任何意见都将不胜感激。
答案 0 :(得分：100)
模型类包含在模型上操作的方法是很自然的。如果我有一个Book模型，使用方法book.get_noun_count()，它就是它所属的位置 - 我不想写“get_noun_count(book)”，除非该方法实际上本质上属于其他一些包。 （可能 - 例如，如果我有一个用“get_amazon_product_id(book)”访问亚马逊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”使它认为应用程序名称是“模型”。这是Django的一个非常讨厌的黑客攻击;它应该可以在已安装的应用程序列表中搜索前缀匹配。
class Book(models.Model):
class Meta: app_label = "site"
你可能会使用基类或元类来概括这一点，但我还没有打扰过它。
答案 1 :(得分：62)
Django旨在让您构建许多小型应用程序而不是一个大型应用程序。
在每个大型应用程序中都有许多小型应用程序正在努力获得自由。
如果你的models.py感觉很大，那你就做得太多了。停止。放松。分解。
查找较小的，可能可重复使用的小型应用程序组件或部件。您不必实际重用它们。试想一下它们是可以重复使用的。
考虑您的升级路径并分解您可能希望在某一天更换的应用程序。您不必实际替换它们，但您可以将它们视为编程的独立“模块”，可能会被未来更酷的东西取代。
我们有大约十二个应用程序，每个model.py不超过大约400行代码。他们都非常专注于不到六个不同的类定义。 （这些不是硬限制，它们是对我们代码的观察。）
我们经常分解。
答案 2 :(得分：4)
我无法确定你可能遇到的许多问题。以下是答案的一些可能性：
同一档案中的多个模型
将它们放入单独的文件中。如果存在依赖关系，请使用import来拉入 其他型号。
models.py
中的无关逻辑/实用函数将额外的逻辑放入单独的文件中。
从数据库中选择一些模型实例的静态方法
在单独的文件中创建新的Manager。
明显与模型相关的方法
save，__ unicode__和get_absolute_url就是例子。