Python-сообщество

Здравствуйте Вам.

Не закидывайте помидорами, но вопрос от новичка, пытающего поднять проект на Django.
Ни как не могу понять, что такое application и по какому принципу он работает с базой данных?
Что-бы не было излишних иссинуаций, поясню:
В примерах говориться что:
Создавать нужно приложение(application) исходя из принципа однофункциональности.
В каждом application есть описание таблиц с которыми это приложение будет работать.
Например есть одна база данных, в ней две таблицы к примеру, одна заказчики, вторая проекты.
К примеру на сайте должна быть одна страница показывающая заказчиков и привязанные к ним проекты, и отдельно страницы в которой мы вносим заказчиков и назначаем им проект.
Значит два приложения, согласно идеологии (best practice): первое которое будет показывать нам связку проект-заказчик, второе которое будет добавлять этих самых заказчиков и назначать им проекты.
Не понимаю как при этом будет в этих applications настраиваться models.py?
И как тогда в этих приложениях работать с таблицами.

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

У меня идеологическое не понимание как это работает.
С одним application в проекте все ясно.

Разъясните пожалуйста.
Спасибо.
Николай.

Отредактировано erl (Июнь 18, 2017 21:25:37)

erl
Да, каша, однако. Попробую объяснить.
Приложения (applications) в терминах Джанго, это отдельные независимые модули, каждый из которых реализует свой собственный независящий от других модулей функционал. Из коробки джанга предоставляет несколько стандартных приложений, например ‘django.contrib.admin’, которое инкапсулирует все, что касается админки. Вы можете подключить это приложение к своему проекту, можете не подключать - ваш код никак не зависит от наличия или отсутствия админки. В идеале приложение должно быть именно таким - ваш остальной код не меняется, при подключении приложения, вы просто получаете новый функционал. Это не всегда достижимо, бывает так, что приложения используют друг-друга. В этом случае хорошим критерием я считаю возможность повторного использования кода. Если какую-то часть проекта вы реализовали отдельным приложением, то вы можете использовать это приложение в нескольких проектах, просто подключая его к нужным проектам.

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

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

Спасибо за ответ.
Но это не разрушило тупика в башке.

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

И здесь теперь еще одна не стыковка, зачем тогда вообще нужен application? Только для переиспользования?

Приведите, пример какой нибудь общий, без примера не пойму логической задачи этого объекта (application)?
Было бы супер если бы было разъяснено на примере двух applications, код не нужно.

Мне нужно логически понять что оно все значит.
И по какому критерию делить, что бы на этапе проектирования понимать что выделять в отдельный модуль. А переиспользовать придется, потому что уже видны куски задач которые можно использовать для решений. Только бы понять что выделить.
Извините за настойчивость, но не сочтите за труд, помочь разобраться.
Спасибо,
Николай.

P.s. И не было бы каши разве я спрашивал бы. Я надеюсь с вашим опытом в этом вопросе, мы кашу эту размешаем и съедим. Благодарю сердечно.

Отредактировано erl (Июнь 19, 2017 14:18:32)

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

erl
И здесь теперь еще одна не стыковка, зачем тогда вообще нужен application?

А придумайте, как бы вы по-другому смогли взять и подключить к вашему проекту систему онлайн оплаты или ckeditor. Ну или представьте такой вариант: вы продаете систему Электронный Дневник. У вас есть несколько киллер-фич, типа модуль “Домашнее задание” или модуль “Контрольная работа”. Каждый модуль вы продаете отдельно, если мне не нужно домашнее задание, я его не покупаю.

Да, согласен с Вами, все стало понятнней.

Большое спасибо.

Должны ли независимые приложения быть в одном проекте или можно их держать в разных?

Добрый день.

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

3ipp
Вам не нужно третье “приложение”, просто напишите свой класс где угодно и импортируйте его.

Подскажите, а где правильно разместить модули с такими классами. Поместил в отдельную папку, написал юнит тест для тестирования работы класса, но он не запускается при полном тестировании, только если явно указать к нему путь при запуске тестов. Как я понял из документации, модули тестирования ищутся только в папках зарегистрированных аппов. Как правильно разместить тогда какую то общую логику? Или ее тест нужно прописывать в тестах приложении (что мне кажется не очень удобным).