Как вы управляете своими приложениями Django?

Жестких правил нет, но я бы сказал, что лучше ошибиться в сторону более специализированных приложений. В идеале приложение должно обрабатывать только одну функциональную задачу: т. е. «помечать» или «комментировать», или «авторизация/авторизация», или «публикации». Этот тип дизайна также поможет вам повторно использовать доступные приложения с открытым исходным кодом вместо того, чтобы заново изобретать колесо (например, Django поставляется с авторизация и комментирует приложения, django-tagged или django-taggable почти наверняка сделает то, что вам нужно, и т. д.).

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

Вы должны попытаться разделить проект на максимально возможное количество приложений. Для большинства проектов приложение не будет содержать более 5 моделей. Например, такой проект, как SO, будет иметь отдельные приложения для UsersProfiles, Questions, Tags (для этого есть готовое в django) и т. д. Если бы была система со статическими страницами, это тоже было бы отдельным приложением (есть готовые). для этой цели). Вы также должны попытаться сделать свои приложения как можно более универсальными, чтобы вы могли повторно использовать их в других проектах. Есть хорошая презентация многоразовых приложений.

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

В моем проекте у меня есть приложение календаря с собственным объектом Event в его моделях. У меня также настроена база данных о совместном использовании автомобилей, и для времени отправления и продолжительности я использую объект Event календаря прямо в своих таблицах RideShare. База данных совместного использования автомобилей поддерживает календарь и получает все хорошие возможности экспорта .ics и представления календаря из приложения календаря «бесплатно».

Есть несколько хитростей, позволяющих повторно использовать приложения, например, назвать каталог шаблонов: project/app2/templates/app2/index.html. Это позволяет обращаться к app2/index.html из любого другого приложения и получать правильный шаблон. Я выбрал это, глядя на встроенные многоразовые приложения в самом Django. Pinax немного монструозный по размеру, но он также демонстрирует хорошую многоразовую структуру приложения.

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

Хороший вопрос, который следует задать себе при принятии решения о написании приложения: «Могу ли я использовать это в другом проекте?». Если вы думаете, что сможете, то подумайте, что нужно сделать, чтобы сделать приложение как можно более независимым; Как можно уменьшить количество зависимостей, чтобы приложение не зависело ни от чего конкретного конкретного проекта.

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

• Предоставление каждому приложению собственного urls.py
• Разрешить передачу типов моделей в качестве параметров, а не явно указывать, какие модели используются в ваших представлениях. Общие представления используют этот принцип.
• Сделайте ваши шаблоны легко переопределяемыми, передав какой-то параметр template_name в ваш urls.py.
• Убедитесь, что вы можете выполнять обратный поиск URL с вашими объектами и представлениями. Это означает именование ваших представлений в urls.py и создание методов get_absolute_url в ваших моделях.
• В некоторых случаях, таких как тегирование, GenericForeignKeys можно использовать для связывания модели в вашем приложении с любой другой моделью, независимо от того, есть ли у нее ForeignKeys, «оглядывающиеся» на нее.

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

Однако знание того, каким должен быть сайт, является основным. ;)