أفضل ممارسات Django: المشاريع مقابل التطبيقات

غالبًا ما يكون تعريف Django لـ “التطبيق” و “المشروع” محيرًا للقادمين الجدد، في هذا المنشور سنقوم بفحص المفاهيم الأربعة الرئيسية لهندسة Django من خلال إنشاء تطبيق ويب أساسي للمدونة.

الخطوة الأولى ، دائمًا ، هي تثبيت Django في بيئة افتراضية مخصصة.

لنفترض أننا نقوم بإنشاء دليل  code  على سطح المكتب (أنا أستخدم جهاز Mac). ستكون الأوامر على النحو التالي:

$ cd ~/Desktop
$ mkdir code && cd code
$ pipenv install django~=3.1.0
$ pipenv shell
(code) $

نحن نعمل الآن ضمن بيئة افتراضية مع تثبيت Django.

المشروع

المشروع هو تطبيق ويب يستخدم Django لا يوجد سوى مشروع واحد والعديد من “التطبيقات” بداخله. لذلك بالنسبة لتطبيق الويب الخاص بالمدونة ، نحتاج إلى إنشائه وتعيين اسم مثل  config.

(code) $ django-admin startproject config .
(code) $ tree
.
├── Pipfile
├── Pipfile.lock
├── config
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
└── manage.py

ملاحظة لقد قمت بإضافة الفترة الاختيارية. في نهاية الأمر بحيث يتم تضمين الملفات في الدليل الحالي.

بخلاف ذلك ، سينشئ Django تلقائيًا دليلًا إضافيًا باسم مشروعنا ثم يضيف ملفات البداية داخل هذا الدليل ، والتي تبدو زائدة عن الحاجة بالنسبة لي ، لكن بعض المطورين يحبون هذا النهج.

INSTALLED_APPS

داخل ملف settings.py الذي تم إنشاؤه حديثًا ، يوجد تك يسمى INSTALLED_APPS وهو عبارة عن قائمة بتطبيقات Django داخل مشروع.

يأتي Django مع ستة تطبيقات مدمجة وهي على الشكل التالي :

# config/settings.py
INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]

التطبيقات

تطبيق Django عبارة عن مكتبة صغيرة تمثل جزءًا منفصلًا من مشروع أكبر، فعلى سبيل المثال قد يحتوي تطبيق الويب الخاص بالمدونة على تطبيق  posts ، وواحد للصفحات الثابتة مثل صفحة حول الموقع تسمى  pages ، وتطبيق آخر يسمى payments  لتحصيل رسوم المشتركين الذين قاموا بتسجيل الدخول.

يمكننا إضافة تطبيق باستخدام الأمر startapp لذلك دعونا نضيف تطبيق  posts  الآن.

(code) $ python manage.py startapp posts
(code) tree
.
├── config
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── manage.py
└── posts
    ├── __init__.py
    ├── admin.py
    ├── apps.py
    ├── migrations
    │   └── __init__.py
    ├── models.py
    ├── tests.py
    └── views.py

تم إنشاء تطبيق  posts و هو يأتي مع الملفات المرتبطة به.

و غالبًا ما يتم إضافة ملف urls.py بالإضافة إلى تلك الملفات.

كما يجب علينا أيضًا إضافة التطبيق إلى إعداد INSTALLED_APPS وإلا فلن يتعرف عليه مشروع Django.

# config/settings.py
INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'posts', # new
]

سترى طرقًا مختلفة لتصميم التطبيق من خلال الولوج إلى عالم الشغل، ولكن أفضل الممارسات العامة هي نفسها: كل تطبيق من تطبيقات Django يجب أن يفعل شيئًا واحدًا.

حزم الطرف الثالث

حزمة الطرف الثالث عبارة عن تطبيق Django قديم بسيط تم تصميمه ليكون قابلاً للتوصيل في أي مشروع موجود باستخدام أدوات حزم Python.

يمكنك مشاهدة الدرس التالي حول تطبيقات الطرف التالث ولن يستغرق الأمر سوى بضع خطوات إضافية.

هذه حالة يمكننا فيها رؤية قوة فصل الوظائف إلى تطبيقات أصغر. و من السهل مشاركتها إما ضمن مشروع أكبر أو داخل شركة أو نشرها على الملأ مثل حزمة الطرف الثالث.

اصطلاحات تسمية التطبيقات

يجب أن يتبع اسم التطبيق إرشادات Pep 8 ، أي يجب أن يكون قصير، ولا تتضمن أرقامًا أو شرطات أو نقاطًا أو مسافات أو أحرفًا خاصة.

قد تبدو تطبيقات Django معقدة عندما تبدأ معها ، لكنها توفر البنية والمرونة التي تشتد الحاجة إليها لأي تطبيق ويب Django.