получение models.py огромного, что лучший способ состоит в том, чтобы разбить его?
Одна вещь добавить к тому, что люди сказали выше. Если у Вас есть блок, содержащий значение только для чтения (например, MaxFooCount только для чтения = 4;), можно изменить значение, которое вызов блоков видит путем поставки новой версии того блока с различным значением (например, MaxFooCount только для чтения = 5;)
, Но с константой, это было бы свернуто в код вызывающей стороны, когда вызывающая сторона была скомпилирована.
при достижении этого уровня мастерства C# Вы готовы к книге Bill Wagner, Эффективному C#: 50 Особенных методов Улучшить Ваш C#, Который отвечает на этот вопрос подробно, (и 49 других вещей).
3 ответа
Django разработан, чтобы позволить вам создавать множество небольших приложений вместо одного большого.
Внутри каждого большого приложения есть множество маленьких приложений, которые пытаются быть бесплатными.
Если ваш models.py кажется большим, вы делаете слишком много. Стоп. Расслабьтесь. Разобрать.
Найдите более мелкие, потенциально многократно используемые небольшие компоненты или части приложения. Вам не нужно на самом деле повторно использовать их. Просто подумайте о них как о потенциально пригодных для повторного использования.
Обдумайте пути обновления и разложите приложения, которые вы, возможно, захотите когда-нибудь заменить. Вам не нужно на самом деле заменять их, но вы можете рассматривать их как отдельный «модуль» программирования, который в будущем может быть заменен чем-то более крутым.
У нас их около дюжины. приложения, каждая модель . py - это не более 400 строк кода. Все они довольно сосредоточены на менее чем полдюжине определений дискретных классов. (Это не жесткие ограничения, это наблюдения за нашим кодом.)
Мы выполняем декомпозицию рано и часто.
Естественно, что классы моделей содержат методы для работы на модели. Если у меня есть модель Book с методом book.get_noun_count () , это то, чему она принадлежит - я не хочу писать « get_noun_count (book) », если метод действительно не принадлежит какому-то другому пакету. (Это может быть - например, если у меня есть пакет для доступа к API Amazon с « get_amazon_product_id (book) ».)
Я съежился, когда в документации Django предлагалось поместить модели в один файл, https://code.djangoproject.com/ticket/3591
Единственная уловка заключается в том, что вам нужно явно указать приложение каждой модели из-за ошибки в Django: предполагается, что имя приложения является третьим. до последней записи в пути к модели. "site.models.Book" дает "сайт", что правильно; "site.models.book.Book" заставляет его думать, что название приложения - "модели". Это довольно неприятный прием со стороны Django; вероятно, ему следует поискать совпадение по префиксу в списке установленных приложений.
class Book(models.Model):
class Meta: app_label = "site"
Возможно, вы могли бы использовать базовый класс или метакласс, чтобы обобщить это, но я пока не озаботился этим.
Я не могу понять, какая из многих возможных проблем может быть у вас. Вот несколько вариантов с ответами:
несколько моделей в одном файле
Поместите их в отдельные файлы. Если есть зависимости, используйте import для извлечения дополнительные модели.
посторонняя логика / служебные функции в models.py
Поместите дополнительную логику в отдельные файлы.
статические методы для выбора некоторых экземпляров модели из базы данных
Создайте новый Менеджер в отдельном файле.
методы, очевидно связанные с моделью
save, __unicode__ и get_absolute_url, являются примерами.