Чем проект отличается от приложения в терминологии django

Обновлено: 02.07.2024

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

Этот реестр называется apps и доступен в django.apps:

Проекты и приложения¶

Термин проект описывает веб-приложение Django. Пакет проекта Python определяется главным образом модулем настроек, но обычно он содержит и другие вещи. Например, когда вы запускаете django-admin startproject mysite, вы получаете каталог проекта mysite, содержащий пакет mysite Python с settings.py, urls.py, asgi.py и wsgi.py. Пакет проекта часто дополняется такими элементами, как фикстуры, CSS и шаблоны, которые не привязаны к конкретному приложению.

Корневой каталог проекта (тот, который содержит manage.py ) обычно является контейнером для всех приложений проекта, которые не устанавливаются отдельно.

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

Приложения включают некоторую комбинацию моделей, представлений, шаблонов, тегов шаблонов, статических файлов, URL-адресов, ПО промежуточного слоя и т. д. Обычно они подключаются к проектам с параметром INSTALLED_APPS и, при необходимости, с другими механизмами, такими как URLconfs, параметр MIDDLEWARE, или наследование шаблонов.

Важно понимать, что приложение Django представляет собой набор кода, который взаимодействует с различными частями платформы. Нет такой вещи, как объект Application. Однако есть несколько мест, где Django необходимо взаимодействовать с установленными приложениями, в основном для настройки, а также для самоанализа. Вот почему реестр приложений поддерживает метаданные в экземпляре AppConfig для каждого установленного приложения.

Нет ограничений на то, что пакет проекта не может также считаться приложением, иметь модели и т. д. (что потребует его добавления в INSTALLED_APPS).

Настройка приложений¶

Чтобы настроить приложение, создайте модуль apps.py внутри приложения, а затем определите там подкласс AppConfig.

Когда INSTALLED_APPS содержит пунктирный путь к модулю приложения, по умолчанию, если Django находит только один подкласс AppConfig в подмодуле apps.py, он использует эту конфигурацию для приложения. Это поведение можно отключить, задав для AppConfig.default значение False .

Если модуль apps.py содержит более одного подкласса AppConfig, Django будет искать один из них, где AppConfig.default имеет значение True .

Если подкласс AppConfig не найден, будет использоваться базовый класс AppConfig.

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

Для авторов приложений¶

Если вы создаете подключаемое приложение под названием «Рок-н-ролл», вот как вы должны указать правильное имя для администратора:

RockNRolllConfig будет загружен автоматически, если INSTALLED_APPS содержит 'rock_n_roll' . Если вам нужно предотвратить это, установите по умолчанию значение False в определении класса.

Вы можете предоставить несколько подклассов AppConfig с различным поведением. Чтобы указать Django, какой из них использовать по умолчанию, установите по умолчанию значение True в его определении. Если ваши пользователи хотят выбрать конфигурацию, отличную от стандартной, они должны заменить «rock_n_roll» на пунктирный путь к этому конкретному классу в своих настройках INSTALLED_APPS.

Атрибут AppConfig.name сообщает Django, к какому приложению применяется эта конфигурация. Вы можете определить любой другой атрибут, описанный в справочнике по API AppConfig.

Подклассы AppConfig могут быть определены где угодно. Соглашение apps.py просто позволяет Django загружать их автоматически, когда INSTALLED_APPS содержит путь к модулю приложения, а не путь к классу конфигурации.

Если ваш код импортирует реестр приложений в __init__.py приложения, имя apps будет конфликтовать с подмодулем apps. Лучше всего переместить этот код в подмодуль и импортировать его. Обходной путь — импортировать реестр под другим именем:

В предыдущих версиях переменная default_app_config в модуле приложения использовалась для определения класса конфигурации приложения по умолчанию.

Для пользователей приложения¶

Если вы используете «Рок-н-ролл» в проекте под названием anthology , но хотите, чтобы вместо этого он отображался как «Джаз Мануш», вы можете указать свою собственную конфигурацию:

В этом примере показаны классы конфигурации для конкретного проекта, расположенные в подмодуле с именем apps.py . Это условность, а не требование. Подклассы AppConfig могут быть определены где угодно.

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

Конфигурация приложения¶

Объекты конфигурации приложения хранят метаданные для приложения. Некоторые атрибуты можно настроить в подклассах AppConfig. Другие устанавливаются Django и доступны только для чтения.

Настраиваемые атрибуты¶

Полный путь Python к приложению, например. 'django.contrib.admin' .

Этот атрибут определяет, к какому приложению применяется конфигурация. Он должен быть установлен во всех подклассах AppConfig.

Он должен быть уникальным в проекте Django.

Короткое имя приложения, например. 'админ'

Этот атрибут позволяет переименовать приложение, если два приложения имеют конфликтующие ярлыки. По умолчанию используется последний компонент имени. Это должен быть действительный идентификатор Python.

Он должен быть уникальным в проекте Django.

Удобочитаемое имя приложения, например. «Администрация».

Этот атрибут по умолчанию имеет значение label.title() .

Путь файловой системы к каталогу приложения, например. '/usr/lib/pythonX.Y/dist-packages/django/contrib/admin' .

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

Установите для этого атрибута значение False, чтобы Django не выбирал класс конфигурации автоматически. Это полезно, когда в apps.py определен только один подкласс AppConfig, но вы не хотите, чтобы Django использовал его по умолчанию.

Установите для этого атрибута значение True, чтобы Django автоматически выбирал класс конфигурации. Это полезно, когда в apps.py определено более одного подкласса AppConfig, и вы хотите, чтобы Django использовал один из них по умолчанию.

По умолчанию этот атрибут не установлен.

Неявный тип первичного ключа для добавления к моделям в этом приложении. Вы можете использовать это, чтобы сохранить AutoField в качестве основного типа ключа для сторонних приложений.

По умолчанию это значение DEFAULT_AUTO_FIELD .

Атрибуты только для чтения¶

Корневой модуль для приложения, например. 'django.contrib.admin' из 'django/contrib/admin/__init__.py'> .

Модуль, содержащий модели, например. 'django.contrib.admin.models' из 'django/contrib/admin/models.py'> .

Может быть None, если приложение не содержит модуль моделей. Обратите внимание, что сигналы, связанные с базой данных, такие как pre_migrate и post_migrate, генерируются только для приложений, в которых есть модуль моделей.

Методы¶

Возвращает итерацию классов модели для этого приложения.

Требуется полное заполнение реестра приложений.

Настройка приложения. get_model (имя_модели, require_ready=True) [источник] ¶

Возвращает модель с заданным именем model_name . имя_модели нечувствительно к регистру.

Вызывает LookupError, если в этом приложении такой модели не существует.

Требуется полное заполнение реестра приложений, если для аргумента require_ready не задано значение False . require_ready ведет себя точно так же, как в apps.get_model() .

Подклассы могут переопределить этот метод для выполнения задач инициализации, таких как регистрация сигналов. Он вызывается, как только реестр полностью заполняется.

Хотя вы не можете импортировать модели на уровне модуля, где определены классы AppConfig, вы можете импортировать их в ready() , используя оператор импорта или get_model() .

Если вы регистрируете модельные сигналы , вы можете ссылаться на отправителя по его строковой метке вместо использования самого класса модели.

Хотя вы можете получить доступ к классам модели, как описано выше, избегайте взаимодействия с базой данных в вашей реализации ready(). Сюда входят методы модели, выполняющие запросы ( save() , delete() , методы менеджера и т. д.), а также необработанные SQL-запросы через django.db.connection . Ваш метод ready() будет запускаться при запуске каждой команды управления. Например, несмотря на то, что конфигурация тестовой базы данных отделена от рабочих настроек, тест manage.py все равно будет выполнять некоторые запросы к вашей рабочей базе данных!

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

Пакеты пространств имен как приложения¶

Пакеты Python без файла __init__.py известны как «пакеты пространства имен» и могут быть распределены по нескольким каталогам в разных местах на sys.path (см. PEP 420).

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

На самом деле пакет пространства имен находится только в одном месте (т. е. не распределен более чем по одному каталогу).
Класс AppConfig, используемый для настройки приложения, имеет атрибут класса пути, который представляет собой абсолютный путь к каталогу, который Django будет использовать в качестве единого базового пути для приложения.

Если ни одно из этих условий не выполняется, Django вызовет ImproperlyConfigured .

Реестр приложений¶

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

Логический атрибут, для которого устанавливается значение True после полного заполнения реестра и вызова всех методов AppConfig.ready().

Возвращает итерацию экземпляров AppConfig.

приложения. get_app_config (метка_приложения)¶

Возвращает AppConfig для приложения с заданным app_label . Вызывает LookupError, если такого приложения не существует.

приложения. is_installed (имя_приложения)¶

Проверяет, существует ли приложение с заданным именем в реестре. app_name — это полное имя приложения, например. 'django.contrib.admin' .

приложения. get_model (app_label, имя_модели, require_ready=True)¶

Возвращает модель с указанными app_label и model_name . В качестве упрощения этот метод также принимает один аргумент в форме app_label.model_name . имя_модели нечувствительно к регистру.

Вызывает LookupError, если такого приложения или модели не существует. Вызывает ValueError при вызове с одним аргументом, который не содержит ровно одну точку.

Требуется полное заполнение реестра приложений, если для аргумента require_ready не задано значение False .

Установка для require_ready значения False позволяет искать модели во время заполнения реестра приложений, особенно во время второго этапа, когда он импортирует модели. Тогда get_model() имеет тот же эффект, что и импорт модели. Основной вариант использования — настроить классы моделей с такими параметрами, как AUTH_USER_MODEL .

Если для require_ready задано значение False , get_model() возвращает класс модели, который может быть не полностью функциональным (например, могут отсутствовать обратные методы доступа), пока реестр приложения не будет полностью заполнен. По этой причине лучше оставить для параметра require_ready значение по умолчанию True, когда это возможно.

Процесс инициализации¶

Как загружаются приложения¶

При запуске Django django.setup() отвечает за заполнение реестра приложений.

Настраивает Django:

Загрузка настроек.
Настройка ведения журнала.
Если для set_prefix установлено значение True, для префикса сценария преобразователя URL устанавливается значение FORCE_SCRIPT_NAME, если оно задано, или / в противном случае.
Инициализация реестра приложений.

Эта функция вызывается автоматически:

В других случаях его нужно вызывать явно, например, в простых скриптах Python.

Реестр приложений инициализируется в три этапа. На каждом этапе Django обрабатывает все приложения в порядке INSTALLED_APPS .

Сначала Django импортирует каждый элемент в INSTALLED_APPS.

Если это класс конфигурации приложения, Django импортирует корневой пакет приложения, определяемый атрибутом имени. Если это пакет Python, Django ищет конфигурацию приложения в подмодуле apps.py или создает конфигурацию приложения по умолчанию.

На данном этапе ваш код не должен импортировать какие-либо модели!

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

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

После завершения этого этапа можно будет использовать API, работающие с конфигурациями приложений, такими как get_app_config().

Затем Django пытается импортировать подмодуль моделей каждого приложения, если таковой имеется.

Вы должны определить или импортировать все модели в файле models.py или models/__init__.py вашего приложения. В противном случае реестр приложений на этом этапе может быть заполнен не полностью, что может привести к сбоям в работе ORM.

После завершения этого этапа можно будет использовать API, работающие с моделями, такими как get_model().

Наконец, Django запускает метод ready() каждой конфигурации приложения.

Устранение неполадок¶

Вот некоторые распространенные проблемы, с которыми вы можете столкнуться во время инициализации:

AppRegistryNotReady: это происходит, когда импорт конфигурации приложения или модуль моделей запускает код, зависящий от реестра приложения.

Например, gettext() использует реестр приложений для поиска каталогов переводов в приложениях. Для перевода во время импорта вам понадобится gettext_lazy(). (Использование gettext() было бы ошибкой, потому что перевод происходил бы во время импорта, а не при каждом запросе в зависимости от активного языка.)

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

Это исключение также возникает, если вы забыли вызвать django.setup() в автономном скрипте Python.

ImportError: невозможно импортировать имя . Это происходит, если последовательность импорта зацикливается.

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

Данное в Django определение приложения часто сбивает с толку новичков. В этом посте мы рассмотрим четыре основные концепции архитектуры Django, создав простое веб-приложение для блога.

Первым шагом всегда является установка Django в выделенной виртуальной среде. Предположим, мы создаем каталог кода на рабочем столе (я использую Mac). Команды будут следующими:

Теперь мы работаем в оболочке виртуальной среды с установленным Django.

Проект

Проект – это веб-приложение, использующее Django. Существует только один проект и множество «приложений» внутри него. Итак, для нашего веб-приложения блога нам нужно создать его и присвоить имя, например config .

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

УСТАНОВЛЕННЫЕ_ПРИЛОЖЕНИЯ

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

Приложение Django – это небольшая библиотека, представляющая собой отдельную часть более крупного проекта. Например, в нашем веб-приложении блога может быть приложение для сообщений , одно для статических страниц, таких как страница "О нас" с именем pages , и еще одно приложение с названием платежи для взимания платы с зарегистрированных подписчиков.

Мы можем добавить приложение с помощью команды startapp, поэтому давайте добавим приложение posts. Используя команду дерева, мы можем увидеть нашу полную обновленную структуру.

Приложение post было создано и поставляется с собственными связанными файлами. Часто вам также потребуется добавить сюда файл urls.py.

Мы также должны добавить приложение в наш параметр INSTALLED_APPS, иначе проект Django не распознает его.

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

Сторонние пакеты

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

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

Соглашения об именах приложений

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

Заключение

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

Тема WordPress Bridge

Тема Salient WordPress

Некоторое время назад я провел некоторое тестирование в качестве фреймворка Django, и только теперь, когда я протестировал его снова, я заметил, что есть две команды, которые меня смутили:

А еще у нас есть:

Я не помню, чтобы мне приходилось использовать команду django-admin startapp в последние несколько раз, когда я ее использовал. Это новая опция?

У меня есть несколько вопросов:

В чем разница между одним и другим?

Что такое "проект" и что такое "приложение" для Django?

Есть ли различия в структуре?

2 ответа

Во-первых, давайте посмотрим на структуру каталогов, которая создается при создании проекта:

Проект, созданный с помощью команды django-admin startproject mysite, для информации.

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

Внутренний каталог mysite, в свою очередь, является созданным проектом Django. Поскольку определение в глоссарии гласит, что проект представляет собой пакет Python (каталог кода), который содержит все настройки рассматриваемого экземпляра Django. Он также может содержать параметры базы данных, общие параметры приложения и многое другое.

Сам проект мало что делает, потому что, согласно философии Django, проект должен состоять из приложений.

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

Например, если вашему приложению (проекту) потребуется область блога, вы создадите для нее приложение, но ТОЛЬКО для этого. В этом приложении вы определите все необходимые структуры таблиц базы данных и все бизнес-правила для функционирования блога.

Но я хочу создать систему управления доступом для пользователей в своем блоге, хорошо, но сделайте это в другом приложении. Нет системы управления пользователями? Другое приложение. Другими словами (что почти то же самое), приложения несут ответственность за запрет аспектов приложения/проекта и могут быть повторно использованы в любом количестве проектов.

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

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

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

Разница между проектом и приложением в пунктах руководства по Django python

Автор сообщения: Сачин Пагар
Запись опубликована: 15 января 2021 г.
Категория записи: наука о данных
Комментарии к сообщениям: 0 комментариев

Проект — это набор приложений. в то время как приложение представляет собой небольшой суб
модуль в проекте, который отвечает за обработку одной функции
Электронная коммерция
Аутентификация продукта клиента

Разница между проектом и приложением в Django Python Tutorials Points

В приведенном выше примере электронная коммерция — это проект и клиент, продукт, аутентификация
и т. д. — это связанные с ним приложения.
Если вы объедините их все в одно приложение, внесение изменений в код станет сложной задачей
. Если вы хотите изменить способ отображения продукта, вы должны сначала
выполнить поиск продукта, а затем внести изменения, вы также должны иметь в виду,
что эти изменения не влияют на другие приложений.
Приложение обеспечивает модульность в проекте.
Поддержка проекта становится проще.
Это снижает сложность.
Еще одна главная особенность приложения заключается в том, что если вы хотите создать другой проект
и там также нужно такое же клиентское приложение, тогда вы просто удаляете или копируете приложение
и добавляете в этот проект без внесения каких-либо изменений.
Проект — это веб-приложение, которое мы создаем с помощью Django. .Таким образом, приложение
называется эффективным, если оно имеет несколько приложений.т.е. одно приложение для одной функциональности и
другое приложение для функциональности.
Приложения (это похоже на большой контейнер)
Приложение Django можно повторно использовать, т.е. вы можете использовать приложения в нескольких проектах с небольшими затратами или без< br />модификация .но вам нужно создать другой проект для компании того же типа.
Предположим, вы создаете проект для компании электронной коммерции, тогда вы не можете повторно использовать
его в другой компании в другой электронной коммерции компания, другой проект компании
отличается, вам нужно снова написать код для этой компании. Таким образом, вы используете /создаете
несколько приложений в проекте, и с помощью этих приложений вы можете создать проект
очень быстро. клиентское приложение одинаково для обеих компаний, вы можете использовать его повторно, и в обоих проектах
также есть различные приложения. Таким образом, с небольшими изменениями или без изменений вы
можете просто скопировать или удалить это приложение и добавить в другой проект. Это экономит время и деньги
эффективно.
Несколько разработчиков могут работать над разными компонентами/приложениями и создавать проект
в очень короткие сроки. меньше времени.
То есть командная работа, что снижает количество ошибок и повышает качество
проекта.
Каждый разработчик мастер своего дела и им приходится управлять фиксированным типом< br />компонент (приложение). Таким образом, они могут управлять им легче, чем инженер, управляющий
всем проектом.
Блог
комментарии сообщения Вход/выход
p1 p2
p3
Здесь вы видите разные приложения для разных задач. Над этим
компонентом одновременно могут работать несколько человек.

В этой статье мы увидели разницу между проектом и приложением в Django Python Tutorials Points, поэтому в этом разделе у вас есть какие-либо вопросы, а затем можете задать их мне

Читайте также: