Джанго: «проекты» против «приложений»

171

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

В проектах может быть много приложений. Приложения могут совместно использоваться многими проектами. Хорошо.

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

Если это так... в терминах пространства имен Django project.app, я склонен использовать myproduct.myproduct, но, конечно, это не разрешено (но приложение, которое я создаю, является моим проектом, а мой проект приложение!). Поэтому я полагаю, что, возможно, я должен подойти к Django, построив одно приложение на "значительную" модель, но я не знаю, где рисовать границы в моей схеме, чтобы отделить ее от приложений - у меня много моделей с относительно сложными отношениями.

Я надеюсь, что там будет общее решение...

Теги:
namespaces
project-organization

6 ответов

50
Лучший ответ

Как остановить использование myproduct.myproduct? Что нужно для достижения этого, примерно состоит в том, чтобы сделать это:

django-admin.py startproject myproduct
cd myproduct
mkdir myproduct
touch myproduct/__init__.py
touch myproduct/models.py
touch myproduct/views.py

и т.д. Помогло бы мне, если бы я сказал, что views.py не нужно называть views.py? Если вы можете указать на пути python функцию (обычно package.package.views.function_name), она будет обработана. Просто как тот. Все это "проект" / "приложение" - это просто пакеты python.

Теперь, как вы должны это делать? Вернее, как я могу это сделать? Ну, если вы создадите значительную часть многоразовых функций, например, скажем, редактор разметки, что при создании "приложения верхнего уровня", которое может содержать widgets.py, fields.py, context_processors.py и т.д. - все, что вы, возможно, захотите импорт.

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

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

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

  • Настройка по умолчанию Django не делает этого.
  • Часто я хочу создать основное приложение, поэтому создаю его, обычно называемый website. Однако на более позднем этапе мне может понадобиться разработать оригинальную функциональность только для этого сайта. Чтобы сделать его съемным (независимо от того, выполняю ли я когда-либо), я, как правило, создаю отдельный каталог. Это также означает, что я могу отказаться от указанной функции, просто отменив этот пакет из конфигурации и удалив папку, а не сложное удаление правильных URL-адресов из глобальной папки urls.py.
  • Очень часто, даже когда я хочу сделать что-то независимым, ему нужно где-то жить, пока я смотрю за ним/делаю его независимым. В основном вышеприведенный случай, но для вещей, которые я собираюсь сделать родовыми.
  • Моя папка верхнего уровня часто содержит несколько других вещей, включая, но не ограничиваясь, скрипты wsgi, sql-скрипты и т.д.
  • django расширения управления зависят от подкаталогов. Поэтому имеет смысл правильно указывать пакеты.

Короче говоря, причина, по которой существует конвенция, такая же, как и любая другая конвенция - она ​​помогает, когда дело касается других, работающих с вашим проектом. Если я вижу fields.py, я сразу ожидаю, что код в нем будет подклассифицирован в поле django, тогда как если я увижу inputtypes.py, я не могу быть настолько понятным, что это означает, не глядя на него.

Поделиться
  • 22
    +1 ... "Что мешает вам использовать myproduct.myproduct?" - Команда Django «startapp» фактически останавливает вас, как я полагаю, как соглашение. Мне нравятся соглашения, особенно в контексте командных усилий, но я предпочитаю понимать логику, стоящую за ними :)
  • 0
    @ Дольф, а? Я не использовал его с тех пор, как использовал его в первый раз, потому что у меня есть своя собственная команда для создания проекта, который сначала создает модели, а затем автоматически генерирует элементы CRUD для этих моделей. Тем не менее, да, соглашения хороши. Я следую конвенциям Джанго, хотя бы потому, что во многом они имеют смысл.
Показать ещё 1 комментарий
72

Как только вы закончите использовать startproject и startapp, вам нечего мешать комбинировать "проект" и "приложение" в одном пакете Python. Проект действительно не что иное, как модуль settings, и приложение действительно не что иное, как модуль models - все остальное необязательно.

Для небольших сайтов вполне разумно иметь что-то вроде:

site/
    models.py
    settings.py
    tests.py
    urls.py
    views.py
Поделиться
  • 16
    +1 Резюме: в проекте есть settings.py, в приложении - models.py. Они имеют одинаковую структуру уровней. Раньше я думал, что проект на один уровень выше приложения, думаю, я ошибался
  • 1
    @claymation, что нужно включить в настройки (как приложение), чтобы позволить 'python manage.py makemigrations' или 'python manage.py migrate' видеть файл 'models.py' в каталоге 'my product'?
67

Попробуйте ответить на вопрос: "Что мой приложение?". Если вы не можете ответить в одном предложении, тогда, может быть, вы можете разделить его на несколько приложений с более чистым логика.

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

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

Поделиться
  • 9
    +1 за следование философии Unix: faqs.org/docs/artu/ch01s06.html
  • 8
    Я все еще немного борюсь за то, чтобы выложить свое собственное приложение. Я чувствую, что мое основное приложение немного тяжелое, но в то же время я не смог бы преобразовать его во что-то похожее на что-то слабо связанное. Я склоняюсь к мысли, что разделение моих основных основных сущностей на самом деле не будет улучшением, если они все еще сильно зависят друг от друга, и нет необходимости повторно использовать или обобщать на горизонте. Я склоняюсь к «не преждевременно рефакторинг», как интерпретация «не преждевременно оптимизировать»
14

Я нашел следующие сообщения в блоге очень полезными о приложениях и проектах django:

В принципе у вас есть много свободы с django для организации исходного кода вашего продукта.

Поделиться
7

Если так... в терминах пространства имен Django project.app, моя склонность заключается в использовании продукта, но, конечно, это запрещено.

Нет ничего подобного. Его проект никого не ограничивает. Желательно сохранить разумное имя.

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

В общем проекте django есть много приложений (вкладки приложений), которые используются в каждом проекте.

Скажем, что ваш проект выполняет только одну задачу и имеет только одно приложение (я называю его main, поскольку проект вращается вокруг него и вряд ли подключается). Этот проект также по-прежнему использует некоторые другие приложения в целом.

Теперь, если вы скажете, что ваш проект использует только одно приложение (INSTALLED_APPS='myproduct'), так что использование project, определяющее проект как project.app, я думаю, вы должны рассмотреть некоторые моменты:

  • Есть много других вещей, которые код, отличный от приложения в проекте, обрабатывает (базовые статические файлы, базовые шаблоны, настройки... т.е. предоставляет базу).
  • В общем подходе project.app django автоматически определяет схему sql из моделей.
  • Ваш проект будет намного проще построить с помощью обычного подхода.
  • Вы можете определить несколько разных имен для URL-адресов, просмотров и других файлов по своему усмотрению, но я не вижу необходимости.
  • Возможно, вам придется добавить некоторые приложения в будущем, что было бы очень легко с помощью обычных проектов django, которые в противном случае могут стать одинаково или сложнее и утомительно.

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

Поделиться
  • 1
    +1, особенно для main соглашения - это имеет большой смысл для такого оригинального проекта, как этот. Я планирую добавить «повторно используемые» приложения позже, но сейчас это выходит за рамки моего внимания.
0

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

Представьте, что вы создаете большое динамическое веб-приложение на основе JavaScript.

Вы можете создать затем в приложении django с именем, например, "FrontEnd" < - в приложении thins вы будете отображать контент.

Затем вы создаете несколько бэкэнд-приложений. Например, приложение "Комментарии" , которое будет хранить комментарии пользователей. И приложение "Комментарии" ничего не отображает. Это будет просто API для запросов AJAX вашего динамического JS веб-сайта.

Таким образом, вы всегда можете использовать свое приложение "Комментарии" . Вы можете сделать его открытым исходным кодом без открытия источника всего проекта. И вы сохраняете чистую логику вашего проекта.

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню