Ответ 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 предоставляет один логический набор операций и делает это хорошо.