4.1تطوير الويب الخلفي مع Django
الأساسي في 30 ثانية
- Django = «شامل بكل البطاريات» : رسم الكائنات العلائقية (ORM) (القاعدة تُدار ككائنات بايثون)، والهجرات (migrations) (تطور دون SQL يدوي)، ولوحة الإدارة (admin) المولدة تلقائيا والمصادقة (auth) متوفرة أصلا.
- مسار MVT :
models.py(البيانات) ←urls.py(المسارات) ←views.py(المنطق) ← قالب.html(العرض) ؛ وmakemigrations + migrateبعد كل نموذج. - منعكس نبيل : تبني اتفاقيات MVT بدلا من محاربتها — فـ Django يفرض بنية مقيدة في البداية، ومنقذة بعد ذلك.
حالة مصغرة متسلسلة — نبيل يعرض مبيعاته في الجزائر
نبيل، محلل بيانات مبتدئ في الجزائر، يقضي أيامه في إعادة إرسال ملف CSV نفسه للمبيعات إلى زملائه. قرر بناء مكتب خلفي مصغر مع Django : نموذج بيع (المدينة، المبلغ، التاريخ)، وهجرات تنشئ الجدول دون SQL، ولوحة الإدارة المولدة تلقائيا حيث يستعرض الفريق المبيعات ويرشحها دون إزعاجه. في أسبوع واحد، صار ملف CSV الأسبوعي تطبيقا يستعلم عنه كل واحد بنفسه. أول محطة في الخيط الرابط : من المحلل الذي يرسل الملفات إلى المطور الذي يعرض خدمة.
الحالة نفسها تعود في الدرس والمخطط والسكربت وتحدي 48 ساعة — وتتواصل في 4.2 و4.3 و4.4 و4.5.
1. Django «الشامل بكل البطاريات» ومعمارية MVT
Django هو إطار (framework) الويب الكامل في بايثون : يوفر أصلا الإدارة (مكتب خلفي مولد)، ورسم الكائنات العلائقية (ORM) (القاعدة تُدار ككائنات بايثون)، والمصادقة (الحسابات، الأذونات) والأمن (CSRF و XSS والحقن). وتنظيمه يسمى MVT : النموذج (models.py) يصف البيانات، والعرض (Vue) (views.py) يحوي المنطق، والقالب (Template) (.html) يعرض — والتوجيه (urls.py) يربط الروابط بالعروض. ومثل نبيل، نتبنى هذه الاتفاقيات : فهي مقيدة في البداية، ومنقذة بعد ذلك.
2. رسم الكائنات العلائقية والهجرات والإدارة : الثلاثي المنتج
يترجم رسم الكائنات العلائقية (ORM) أصناف بايثون إلى جداول : class Vente(models.Model) بحقول (CharField, DecimalField, DateField) يصير جدولا، وVente.objects.filter(ville="Alger") يعوض SELECT — دون SQL يدوي. وتؤرخ الهجرات (migrations) كل تغيير في النموذج : python manage.py makemigrations ثم migrate، فتتطور القاعدة بنظافة، في الفريق كما في الإنتاج. وتمنح لوحة الإدارة (admin) (المفعلة عبر createsuperuser، على /admin) منذ الدقائق الأولى مكتبا خلفيا لاستعراض البيانات وتصحيحها. وهكذا يكسب نبيل أول خدمة يقدمها للفريق.
ومتى نختار Django ؟ صفحات تُخدم من الخادم + حسابات + مكتب خلفي ← Django. وJSON خالص يستهلكه واجهة منفصلة ← الأفضل واجهة برمجة (API) خفيفة (انظر 4.2). وحتى مع رسم الكائنات العلائقية، تبقى أسس SQL مفيدة للتحسين وفهم ما يجري تحت الغطاء.
🔎 مثال ملموس — 🔎 مثال ملموس — مبيعات نبيل بمعمارية MVT
خطوات نبيل الأربع، مع الواجهات الحقيقية :
models.py ← class Vente(models.Model): ville, montant, date
shell ← makemigrations + migrate (جدول مُنشأ، دون SQL)
urls.py ← path('ventes/', vues.liste_ventes)
views.py ← Vente.objects.filter(ville="Alger") ← templateالقراءة : النموذج والمسار والعرض والقالب — كل في مكانه.
الدرس : لوحة الإدارة تعرض هذه المبيعات دون برمجة مكتب خلفي.
مفردات القسم
- Django
- إطار (framework) ويب بايثون الكامل («الشامل بكل البطاريات») : لوحة إدارة ورسم كائنات علائقية ومصادقة وأمن متوفرة أصلا.
مثال بسيط: يبني فيه نبيل مكتب مبيعاته الخلفي في أسبوع.
ما ليس كذلك: تكديس سكربتات دون بنية ولا حسابات.
رد فعل: صفحات + حسابات + إدارة ؟ فكر في Django أولا.
- MVT (نموذج-عرض-قالب)
- تنظيم كود Django : النموذج (البيانات)، والعرض (المنطق)، والقالب (عرض HTML)، يربط بينها التوجيه urls.py.
مثال بسيط: مبيعات نبيل : نموذج Vente، وعرض liste_ventes، وقالب ventes.html.
ما ليس كذلك: سكربت وحيد يخلط SQL والمنطق و HTML.
رد فعل: لكل ملف، اسأل : بيانة أم منطق أم عرض ؟
- ORM
- تدبير القاعدة عبر كائنات بايثون (Vente.objects.filter(...)) بدلا من كتابة SQL.
مثال بسيط: يرشح نبيل مبيعات الجزائر دون كتابة SELECT.
ما ليس كذلك: SQL مدمج مع متغيرات في الكود.
رد فعل: اقرأ الاستعلامات المولدة حين تتباطأ صفحة.
- هجرة (migration)
- ملف يترجم تغييرات نماذجك إلى تعديلات في القاعدة (makemigrations + migrate).
مثال بسيط: يضيف نبيل حقل التاريخ : هجرة واحدة تطور الجدول في كل مكان.
ما ليس كذلك: ALTER TABLE يدوية في الإنتاج.
رد فعل: لا بنية معدلة خارج الهجرة أبدا.
في التطبيق — عمليا — اكتشاف Django ولوحة إدارته
- في بيئة افتراضية (venv)، ثبت Django (pip install django) وأنشئ مشروعا : « django-admin startproject monsite »، ثم تطبيقا « python manage.py startapp ventes ».
- صرح بنموذج (مثلا بيع : المدينة، المبلغ، التاريخ)، ثم أطلق « makemigrations » و« migrate » : ولاحظ الجدول المُنشأ دون SQL.
- أنشئ مستعملا خارقا (« createsuperuser »)، وأطلق « runserver » واستكشف لوحة الإدارة : وأضف أسطرا ورشحها.
- أضف رابطا وعرضا يستعلم رسم الكائنات العلائقية وقالبا يعرض القائمة.
نص جاهز للقول — عرض مكتبه الخلفي (30 ثانية)
«معكم نبيل : مبيعاتنا تعيش في نموذج Django، والقاعدة تتطور بالهجرات، والفريق يستعرضها في لوحة الإدارة دون أن يطلب مني CSV. الروابط والعروض والقوالب تتبع MVT : فكل واحد يعرف أين يبحث.»
يُقال في اجتماع الفريق ؛ واعرض لوحة الإدارة مباشرة.
نموذج نسخ-لصق — تطبيق Django مصغر (كود مختبر)
# ventes/models.py
from django.db import models
class Vente(models.Model):
ville = models.CharField(max_length=80)
montant = models.DecimalField(max_digits=10, decimal_places=2)
date = models.DateField()
def __str__(self):
return f"{self.ville} — {self.montant}"
# ventes/views.py
from django.shortcuts import render
from .models import Vente
def liste_ventes(request):
ventes = Vente.objects.filter(ville="Alger").order_by("-date")[:20]
return render(request, "ventes/liste.html", {"ventes": ventes})
# ventes/urls.py
from django.urls import path
from . import views
urlpatterns = [
path("ventes/", views.liste_ventes, name="liste-ventes"),
]
# الأوامر :
# python manage.py makemigrations && python manage.py migrate
# python manage.py createsuperuser && python manage.py runserver
مشروع أول
يكفي نموذج واحد + لوحة الإدارة : اعرض بياناتك في ساعة قبل برمجة أي صفحة.
تطبيق فريق
مثل نبيل : MVT صارم، وكل تغيير في القاعدة بهجرة، ولوحة الإدارة كمكتب خلفي احتياطي.
بيانات موجودة
استورد ملف CSV إلى رسم الكائنات العلائقية مرة واحدة (سكربت استيراد)، ثم دع Django يخدم : انتهت الملفات المتداولة.
نحو واجهة برمجة
JSON خالص لواجهة منفصلة ؟ احتفظ بنماذج Django وأضف طبقة واجهة برمجة (API) (انظر 4.2) بدلا من إعادة كتابة كل شيء.
✓ ممارسات جيدة
- تبني اتفاقيات MVT بدلا من الالتفاف عليها.
- هاجر منذ النموذج الأول، والإدارة منذ الساعة الأولى.
- حافظ على أسس SQL لتحسين رسم الكائنات العلائقية.
✗ أخطاء شائعة
- محاربة اتفاقيات الإطار.
- كتابة SQL يدوي بدلا من استعمال رسم الكائنات العلائقية.
- اعتبار Django واجهة JSON خالصة وخفيفة.
النقاط الأساسية
- DJANGO = إطار «شامل بكل البطاريات» : إدارة ورسم كائنات علائقية ومصادقة وأمن متوفرة أصلا.
- MVT : النموذج (البيانات) ← الرابط (التوجيه) ← العرض (المنطق) ← القالب (العرض).
- رسم الكائنات العلائقية = القاعدة ككائنات بايثون ؛ والهجرات = تطور دون SQL يدوي.
- الإدارة المولدة تلقائيا : مكتب خلفي منذ الدقائق الأولى. من محلل CSV إلى خدمة معروضة.
تحدي 48 ساعة — طبق غدا
أنشئ مشروع Django واحدا مع نموذج واحد من بياناتك الخاصة، وهاجر، واستكشف لوحة الإدارة واعرض قائمة مرشحة واحدة في قالب.
- أستطيع ذكر MVT ورسم الكائنات العلائقية والهجرات والإدارة.
- أعرف إنشاء نموذج والتهجير دون SQL.
- عندي صفحة Django واحدة تعرض بياناتي.
أسئلة شائعة
Django أم Flask/FastAPI : كيف أختار ؟
Django حين يلزم تطبيق كامل ومنظم : صفحات مخدومة وحسابات وأذونات ومكتب خلفي — فكل شيء متوفر ومتسق، بثمن تبني اتفاقياته. وFlask أو FastAPI حين تلزم خدمة خفيفة ومفصلة، عادة واجهة JSON يستهلكها عميل آخر (انظر 4.2). ويتذكر نبيل : المكتب الخلفي للفريق ← Django ؛ وJSON خالص لواجهة ← واجهة برمجة (API).
هل يلزم معرفة SQL لاستعمال رسم الكائنات العلائقية في Django ؟
لا في البداية : يكفي رسم الكائنات العلائقية للإنشاء والقراءة والترشيح. ونعم متى كبر الأمر : ففهم الجداول والفهارس والاستعلامات المولدة لازم لتحسين الصفحات البطيئة والتنقيح وكتابة الاستعلامات المعقدة التي يعبر عنها رسم الكائنات العلائقية بصعوبة. رسم الكائنات العلائقية + أسس SQL = الثنائي الصحيح.
لماذا يقال إن Django «شامل بكل البطاريات» ؟