Большой макет приложения Django - PullRequest
25 голосов
/ 19 апреля 2010

Я работаю в команде, разрабатывающей сетевой университетский портал, который будет основан на Django. Мы все еще находимся на стадии исследования, и я пытаюсь найти лучший способ выложить среду проекта / разработки.

Моя первоначальная идея состоит в том, чтобы разработать систему как «приложение» Django, которое содержит подпрограммы для разделения различных частей системы. Причина, по которой я намеревался сделать эти «вспомогательные» приложения, заключается в том, что они вообще не будут использоваться вне родительского приложения, поэтому было бы мало смысла распространять их по отдельности. Мы предполагаем, что портал будет установлен в нескольких местах (например, в разных университетах), поэтому основное приложение может быть добавлено в несколько проектов Django для его установки. Поэтому у нас есть свой репозиторий для каждого проекта местоположения, который на самом деле представляет собой просто файл settings.py, определяющий установленные приложения портала, и urls.py перенаправляющий URL-адреса на него.

Я уже начал писать некоторый начальный код и столкнулся с проблемой. Часть кода, который обрабатывает аутентификацию пользователей и профили, кажется, не имеет дома. Концептуально он не принадлежит приложению портала, поскольку не имеет отношения к функционалу портала. Это также, однако, не может быть включено в репозиторий проекта - поскольку я тогда дублировал бы код по репозиторию каждого местоположения. Например, если бы я обнаружил ошибку в этом коде, мне пришлось бы вручную реплицировать исправление для всех файлов проекта местоположения.

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

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

Ответы [ 3 ]

31 голосов
/ 19 апреля 2010

Лучший способ, который я нашел для этого, - это создание приложений, а затем проект для их склеивания. Большинство моих проектов имеют похожие приложения, которые включены в каждый. Электронная почта, заметки, напоминания о действиях, аутентификация пользователя и т. Д. Мой предпочтительный макет выглядит так:

  • Проект /
    • settings.py
    • urls.py
    • views.py
    • ...
  • приложения /
    • электронная почта /
      • urls.py
      • views.py
      • ...
    • примечания /
      • urls.py
      • views.py
      • ...
    • ...

приложения:

Каждое из «приложений» стоит само по себе и, кроме settings.py, не зависит от самого проекта (хотя может полагаться на другие приложения). Одним из приложений является аутентификация и управление пользователями. Он содержит все URL для выполнения своих задач в apps/auth/urls.py. Все его шаблоны находятся в apps/auth/templates/auth/. Все его функции автономны, поэтому, когда мне нужно что-то настроить, я знаю, куда идти.

проект:

* project/ содержит весь клей, необходимый для объединения этих отдельных приложений в окончательный проект. В моем случае я использовал значение settings.INSTALLED_APPS в project/, чтобы определить, какие виды из приложений были мне доступны. Таким образом, если я возьму apps.notes из моего INSTALLED_APPS, все по-прежнему будет работать замечательно, просто без заметок.

Обслуживание:

Эта схема / методология / план также имеет долгосрочные положительные последствия. Позже вы можете повторно использовать любое из приложений, практически без работы. Вы можете протестировать систему снизу вверх, убедившись, что каждое из приложений работает, как предполагалось, прежде чем интегрироваться в целое, помогая быстрее находить / исправлять ошибки. Вы можете реализовать новую функцию, не распространяя ее на существующие экземпляры приложения (если она не в INSTALLED_APPS, они не могут ее увидеть). * * 1068

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

4 голосов
/ 20 апреля 2010

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

  • my_portal
  • auth_module
  • profiles_module
  • application1 (зависит от auth_module)
  • application2 (зависит от auth_module и profile_module)

Я думаю, что тот факт, что «классический» проект Django «содержит» приложения, которые он использует, мешает вам увидеть картинку - на самом деле, в этом нет необходимости. Для проекта, в котором у вас будут какие-то подключаемые модули, я бы предложил организовать приложения в виде яиц и использовать zc.buildout + djangorecipe для управления всем.

Таким образом, вы сможете сохранить ваши модули в плоской одноуровневой структуре. Яйца имеют возможность указывать зависимости, поэтому если вы устанавливаете application1 (см. Выше), auth_module будет установлен автоматически.

Также будет легко развернуть разные конфигурации на разных серверах. Предположим, у вас есть server1, на котором установлено приложение1, и сервер2, на котором установлены приложение1 и приложение2 - вы можете просто иметь две конфигурации:

server1.cfg:

[buildout]
extends = base_deployment.cfg
eggs += application1

server2.cfg:

[buildout]
extends = base_seployment.cfg
eggs += application1
        application2

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

Не говоря уже о том, что вы также можете иметь отдельную конфигурацию для конфигурации разработки (например, с установленными debug = True и Django Debug Toolbar).

4 голосов
/ 19 апреля 2010

Вы должны взглянуть на:

Я обычно использую эту структуру проекта:

  • / djangoproject
    • / приложения
      • / main # основной код
      • / static # каждое вспомогательное приложение может обслуживать статику
      • / app1
      • / static # каждое вспомогательное приложение может обслуживать статику
      • / app2 ...
    • / scripts # manage.py, wsgi, apache.conf, fabfile.py ...
    • / core # ваши библиотеки ...
    • settings.py
    • local_settings.py

Каждое приложение в / apps имеет urls.py, который автоматически включается в основной urls.py. И каждое приложение может быть подмодулем git (или svn external)

Кроме того, используя git, вы можете работать в разных ветках Parallels (master / dev / customerA / customerB ...) и объединять обновления.

Создание настоящего многоразового использования с django не так просто.

...