Подтвердить что ты не робот

Большой макет приложения Django

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

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

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

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

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

4b9b3361

Ответ 1

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

  • Проект /
    • 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, они не могут ее увидеть).

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

Ответ 2

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

  • Django общие отношения
  • Django многоразовые приложения, если вы хотите повторно использовать
  • GIT или любой другой CVS (git отлично подходит для поддержки + развертывания)
  • Fabric, если вам нужны автоматические развертывания/обновления

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

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

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

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

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

Ответ 3

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

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

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

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

Также будет легко иметь разные конфигурации, развернутые на разных серверах. Предположим, у вас есть server1, у которого установлено приложение 1, и server2, на котором установлены как приложение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).