models.py越来越巨大，最好的方法是什么来分解它？
来自我的主pipe的指示：“我想避免在models.py放置任何逻辑，从这里开始，让我们用它作为访问数据库的类，并将所有逻辑保存在使用模型类的外部类中，他们。”
我觉得这是错误的路要走。 我觉得为了保持文件小而保持逻辑不是模型是一个坏主意。 如果逻辑在模型中是最好的，那么无论文件大小如何，这都是它应该去的地方。
那么有没有简单的方法来使用包括？ 在PHP中，我想向主pipebuild议我们只有models.py include（）来自其他地方的模型类。 从概念上讲，这将允许模型拥有我们想要的所有逻辑，但通过增加文件数量（导致冲突等修订控制问题较less）来保持文件的大小。
那么，是否有一种简单的方法可以从models.py文件中删除模型类，但仍然可以使用所有的Django工具？ 或者，对于“large”models.py文件的一般问题，是否有完全不同的优雅的解决scheme？ 任何input将不胜感激。
Django旨在让您创build许多小应用程序，而不是一个大的应用程序。
在每个大型应用程序中都有许多小应用程序正在努力获得自由。
如果你的models.py感觉很大，你做得太多了。 停止。 放松。 分解。
find更小的，可能重复使用的小应用程序组件或组件。 你不必真的重用它们。 只要把它们想成是可重复使用的。
考虑你的升级path，并分解你可能想要replace的应用程序。 您不必实际replace它们，但是您可以将它们视为编程的独立“模块”，将来可能会被更酷的东西取代。
我们有大约十几个应用程序，每个model.py不超过400行代码。 他们都专注于less于大约六分之一的离散类定义。 （这些不是硬性的限制，它们是关于我们的代码的观察。）
我们早期和经常分解。
模型类包含在模型上运行的方法是很自然的。 如果我有一个Book模型，使用方法book.get_noun_count() ，那就是它所属的地方 – 我不想写“ get_noun_count(book) ”，除非方法本质上属于其他包。 （这可能 – 例如，如果我有一个用“ get_amazon_product_id(book) ”访问Amazon API的包get_amazon_product_id(book) 。
当Django的文档build议将模型放在一个单独的文件中时，我感到</s> and不安，我从一开始就花了几分钟的时间来弄清楚如何将它分成合适的子包。
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中的一个错误，你需要明确地设置每个模型的应用程序：它假定应用程序名称是模型path中的倒数第三项。 “site.models.Book”导致“site”，这是正确的; “site.models.book.Book”认为应用程序名称是“模型”。 这在Django方面是非常讨厌的。 它应该可能search已安装的应用程序的列表以匹配前缀。
class Book(models.Model): class Meta: app_label = "site"
你可能可以使用基类或元类来概括这个，但我还没有打扰。
我不能完全得到你可能遇到的许多可能的问题。 这里有一些答案的可能性：
-
多个模型在同一个文件中
把它们放到单独的文件中。 如果存在依赖关系，请使用导入来拉入其他模型。
-
models.py中的无关逻辑/实用function
把额外的逻辑放在单独的文件中。
-
从数据库中select一些模型实例的静态方法
在单独的文件中创build一个新的pipe理器 。
-
方法明显与模型有关
保存，__unicode__和get_absolute_url是例子。
