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

Question

Я просто хотел попробовать построить проект с django. Поэтому у меня (основной) вопрос о том, как управлять таким проектом. Так как я не могу найти какие-либо рекомендации по разделению проекта на приложения.

Давайте возьмем вид SO в качестве примера. Какие приложения вы бы использовали? Я бы сказал, что должны быть приложения "пользователи" и "вопросы". Но что, если бы существовала тематическая система со статическими статьями? Может быть, они также могут получить голоса. Как построить структуру приложений тогда? Одно приложение для «вопросов», «голосов» и «тем» или только одно приложение «контента»?

Понятия не имею, что делать. Может быть, это потому, что я еще не очень много знаю о Джанго, но мне тоже интересно ...

Answer 1

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

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

Answer 2

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

Answer 3

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

Вот несколько способов сделать это:

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

Answer 4

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

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

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

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

Answer 5

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

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