Як краще структурувати Django проект та дизайн вашої Django аплікації?

В попередній статті ми з вами почали з розбору робочого середовища і як зробити його більш ефективним у вашому щоденному житті.

Структура Проекту та Дизайн Аплікації – це основа успішного Django вебсайту

Цього ж разу я спробую надати кілька корисних порад щодо:

• структури Django проекта і
• дизайну та кращих практих створення вашої чергової Django аплікації.

Отже,

Перед тим як поринемо в проекти та аплікації розберемось зовсім коротко в термінології.

Django Проект – це веб проект (будь-то вебсайт чи веб аплікація), створений за допомогою веб-фреймворку Django.

Django Аплікація – це невелика бібліотека коду, яка представляє один аспект цілого вашого проекту. Зазвичай Django Проект складається із кількох (деколи дуже багатьох) Django Аплікацій. Деякі із цих аплікацій є внутрішніми для вашого конкретного проекту і ніколи не використовуватимуться у інших проектах, в той час як інші є зовнішніми і можуть використовуватися вами у інших Django Проектах.

Сторонні Django Пакети (Додатки, Аплікації) – python пакети та Django аплікації створені іншими розробниками, які ви використовуєте у ваших власних проектах.

Почнемо із кількох порад саме по Django Проектах:

Django проект

Структура проекту в Django є досить “слизьким” предметом, адже навіть лідери розробники в Django спільноті притримуються різних підходів у розбудові та структурі проекту.

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

Дефолтний лейаут

Спочатку глянемо на стандартний шаблон проекту, який іде разом з Django:

Модифікований шаблон проекту

Замість того, щоб використовувати дефолтний шаблон проекту, я користуюсь наступною структурою, яку я запозичив від інших Django розробників популярних в Django тусовці.

Сам проект, який генерується командою startproject у даному варіанті потрапляє у папку, яка являється кореневою папкою репозиторію. А вся структура складається із трьох рівнів:

“Корінь Репозиторію” – коренева папка усього проекту. Сюди ми кладемо:

• папку Django проекта, ту що згенерована командою startproject;
• README.rst – невеликий огляд проекту;
• docs/ – папка, що містить усю документацію по проекту;
• design/ – папка, що містить оригінальний дизайн проекту, у тому вигляді який він прийшов від дизайнера;
• .gitignore – файлик, з допомогою якого ми вказуємо git репозиторію, які файли ігнорувати;
• requirements.txt – список залежностей проекту;
• інші файли необхідні для деплойменту проекту на продакшин сервер.

“Корінь Django Проекту” рівень – містить стандартну згенеровану папку командою startproject. Її вміст ми уже з вами оглянули у попередній секції. Окрім того вона може також мати:

• папку з конфігурацією проекту;
• папку із шаблонами;
• папку з медіа та статичними ресурсами;
• ну і звичайно інші аплікації, що ви розробляєте для даного проекту.

“Корінь Конфігурації” – ця папка також генерується командою startproject. Тут зберігається конфігурація проекту (settings.py) і конфігурація url адрес на вебсайті (urls.py). Ця папочка повинна бути пітон пакетом. Тобто містити __init__.py файл.

Ось так може виглядати структура папок та файлів у модифікованому (покращеному) шаблоні проекту:

Останнім часом я клав такий Django проект у окреме віртуальне середовище. Але потім зрозумів, що вони не обов’язково повинні пов’язуватись, і можна в принципі крутити кілька джанго проектів на одному віртуальному середовищі. Тому тепер я розділяю їх. Є окрема папка контейнер для усіх віртуальних середовищ, і є окрема папка контейнер для усіх Django проектів (репозиторіїв у нашому випадку).

Якщо наступного разу також хочете скористатись такою ж структурою проекту, тоді для вас підготував необхідну заготовку проекту. Тут в репозиторії виклав його для вас.

Ось як створювати новий проект з його допомогою:

Звичайно для кожного нового проекту варто обирати свою структуру файлів. Взалежно від розміру проекту та команди оптимальна структура може змінюватись.

Кращі практики дизайну Django аплікації

А тепер кілька порад зі створення, дизайну та підтримки Django аплікацій.

Одна Django аплікація – одна задача

У світі Django є така рекомендація: кожна ваша Django аплікація не повинна виконувати більше, ніж одну задачу у вашому проекті. Не повинна працювати та забезпечувати більше, ніж один аспект вашого проекту.

Тобто заведено тримати аплікації малими.

Щоб перевірити чи ваша аплікація дійсно зроблена згідно даного принципу, маєте сформулювати визначення цієї аплікації одним простим коротким реченням без сполучників (i, та) та без ком. Не виходить? Це майже очевидний признак, що вашу аплікацію треба розбивати на кілька менших аплікацій.

Давайте на прикладі розглянемо даний принцип. Уявимо, що треба розробити вебсайт для конференції. На сайті повинні бути наступні секції та сторінки:

• головна
• події
• новини
• блог
• опис події: місце, учасники, програма, проживання, добирання та інша логістика
• контакт форми
• бронь та купівля квитків

Ось, які Django аплікації я б створив і залучив до даного проекту:

• conference – головна аплікація, яка зв’язуватиме весь код проекту та аплікацій до купи, також імплементуватиме головну сторінку;
• events – створення та публікація подій на сайті;
• news – створення та публікація новин на сайті;
• blog – пости, категорії, різноманітні фільтри та пошук по блогу;
• venue – логістика по конференції, або може увійти в аплікацію conference;
• booking – бронь та купівля квитків;
• contact – форми контактування.

Таким чином кожна із аплікацій займатиметься лише одним аспектом вебсайту. Ми отримаємо 7 аплікацій, 6 із яких будуть незалежними одна від одної, і навіть можуть використовуватись у ваших інших Django проектах. Це ще одна перевага малих модульних Django Аплікацій.

Як називати ваші Django Аплікації?

Досить спірна тема. У кожного свої правила, у когось їх взагалі немає. Я надаю перевагу називати аплікації без залучення особливої фантазії, щоб було “тупо”, але зрозуміло. Без зайвого креативу 🙂

Попередня порада щодо тримання ваших аплікацій малими і зфокусованими на лише одному аспекті проекту спростить вам життя, коли прийдеться давати назву вашим аплікаціям.

Як? Дуже просто. З попереднього прикладу про вебсайт конфереції ми уже можемо взяти згадані назви за назви аплікацій. Аплікація, яка створює блог на сайті? – blog, новини? – news, події? – events. Коротко і зрозуміло.

А тепер уявіть, якщо у вас одна аплікація, яка містить код щодо новин, подій та бронювання квитків. Як назвати таку аплікацію? news_events_booking ? 🙂

Щодо інших правил, то просто рекомендую притримуватись правил стилю коду в мові Python. Там гарно роз’яснено правила та рекомендації по назві модулів та пакетів.

Якщо зовсім коротко, то імена краще мати:

• короткими,
• в нижньому реєстрі,
• без чисел,
• без дефісів,
• без крапок,
• і без інших особливих символів.

Якщо все ж таки потрібно кілька слів в назві – тоді використовуйте підкреслення між словами.

***

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

А які у вас підходи та практики щодо проектів та аплікацій в Django?

Якщо ви лише початківець та хочете більше дізнатись про веб-розробку та навчитись створювати веб-сайти використовуючи мову Python та веб-фреймворк Django? Не пропустіть дану пропозицію:

Веб-розробка з Python i Django для початківців



Практичний посібник по веб-розробці з допомогою Python та Django для початківців. Постійна підтримка та швидкі результати гарантовано.



Детальніше...