Django: лучшая практика для разделения проекта на приложения

Question

Я действительно борюсь со всей этой идеей приложения. Я читал много руководств и руководств по стилю, и я знаю, что я должен попытаться создать специализированные приложения, которые делают ровно одну вещь. Все это имеет смысл, если посмотреть на какой-то простой учебный проект, но как только он попадает в сложный проект реальной жизни, я не могу определить, как я должен рисовать линии между различными приложениями.

Одна из проблем заключается в том, что я хочу иметь один сайт (или несколько сайтов), где пользователь видит много разных вещей. Материал, который должен быть из разных приложений, при соблюдении правил дизайна приложения. Как бы я понял что-то подобное? Моя первая идея состояла в том, чтобы создать одно приложение под названием ui, которое просто обрабатывает ВСЕ виды, которые фактически ведут к шаблону, и все остальные приложения предоставляют модели и вспомогательные функции. Но я боюсь, что приложение ui станет большим.

Чтобы дать вам небольшой пример: Давайте я хочу иметь сайт, где пользователь может выполнить следующие задачи:

• Выберите тему
• установить некоторые опции для выбранного объекта
• загрузки файлы, связанные с его учетной записью
• присвойте некоторые из загруженных файлов теме
• записать некоторые аудиофайлы, которые будут относиться к объекту

Прямо сейчас, я хотел бы создать три приложения:

1. предметов (содержит обрабатываемую модель и некоторые родственные модели)
2. ресурсов (содержит модель ресурсов, обрабатывает загрузку)
3. аудио (ручки все аудио записи и обработки материал)

Но тогда, я должен был бы какой-то main или ui приложение для обработки, как эти ар ps взаимодействовать и создавать фактический сайт, где все приложения каким-то образом задействованы.

Итак, есть ли «правильный» способ сделать это? Или есть какие-то шаблоны, которые я могу использовать? Я также благодарен за ссылки на хорошие ресурсы по этой теме, хотя я уже прочитал немало.

Answer 1

Вам просто нужно убедиться, что ваша структура имеет смысл вы.

Нет необходимости создавать новое приложение для каждой функции, связанной с другой частью логики проекта.

Многоразовые приложения - это совсем другая история, их код в какой-то мере не должен знать об их реализации.

Взгляните на Django's structure вдохновение

Возможная схема для примера:

project_root/ 
    project/ 
     __init__.py 
     settings.py 
     urls.py 
     templates/ 
      app1/ # override stuff 
     static/ 
     media/ 
    app1/ 
     __init__.py 
     admin/ # as a package 
      __init__.py 
      subjects.py 
      resources.py 
      # etc 
     models/ # as a package 
      subjects.py 
      resources.py 
      # etc 
     managers/ 
      __init__.py 
      subjects.py 
      resources.py 
      # etc 
     services/ 
      __init__.py 
      audio.py # upload handler etc 
     views/ 
      __init__.py 
      subjects.py 
     urls/ 
      __init__.py 
      subjects.py 
     templates/ 
      app1/ 
       subject_list.html # override at project level 
     static/ 
      app1/ 
       css/ 
        subject.css # override at project level 
    app2/ 
     __init__.py 
     models.py # holds a Member model or whatever you require 
    manage.py 

Answer 2

Я думаю, что лучший способ, чтобы разграничить приложение примерно эквивалентно тому, как вы разграничить класс по принципу Объектно-ориентированный язык программирования.Вместо переменных и методов вы думаете о моделях и представлениях соответственно:

модели - это состояние объекта, представления используются для просмотра и взаимодействия с состоянием объекта.

Мое эмпирическое правило, создает ли приложение приложение encapsulate определенного набора моделей? Если это так, то я пытаюсь его создать.