Django и организация проекта/приложения

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

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

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

Ответ 1

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

Теперь на ваш вопрос: проект Django представляет собой набор приложений Django - эта часть вы получили правильно. книга Django определяет ее лучше:

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

django book определяет приложение Django как:

"Пакет кода Django, включая модели и представления, который живет вместе в одном пакете Python и представляет собой полное приложение Django."

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

Большинство моих проектов, которые являются внутренними приложениями для нашей компании, имеют встроенное встроенное приложение, которое в значительной степени представляет собой набор шаблонов, css, javascript и т.д.; которые связывают проекты вместе с общим внешним видом. У меня нет просмотров или моделей в этом подключаемом приложении.

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

Хороший пример приложений:

Аутентификация
(у Django уже есть стандартное приложение для проверки подлинности)
поддержка gravatar (у нее есть пинак)
tagging (доступно несколько опций, у Pinax есть один)
helpdesk (мы разработали один из них)

Все вышеперечисленное относится к одной логической проблеме. Они не пытаются быть идеальным решением... Приложение Gravatar не поддерживает OpenID (есть еще одно приложение для OpenID), а внутреннее приложение моей справки не обеспечивает аутентификацию (в нем используется стандартная django приложение для этого).

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

Хорошее приложение Django предоставляет один логический набор операций и делает это хорошо.