دليل انشاء موقع ويب باستخدام python و Django
دليل إنشاء موقع ويب باستخدام Python و Django: من البداية إلى الاحتراف
python django، هل تطمح إلى إنشاء موقع ويب ديناميكي وتفاعلي؟
إذاً، فإن Python و Django هما الأدوات المثالية لتحقيق ذلك.
Python هي لغة برمجة قوية ومرنة، بينما Django هو إطار عمل ويب عالي
المستوى مبني على Python، يوفر لك الأدوات والميزات اللازمة لتطوير مواقع ويب معقدة بكفاءة وسرعة.
في هذا الدليل الشامل، سنأخذك في رحلة خطوة بخطوة لإنشاء موقع ويب
باستخدام Python و Django، بدءًا من تثبيت الأدوات وصولًا إلى نشر موقعك على الإنترنت.
خطوات انشاء موقع ويب باستخدام python و Django
ما الذي سنتعلمه في هذا الدليل؟
1- تثبيت Python و Django: سنتعلم كيفية تثبيت Python و Django على جهازك،
وتهيئتهما للبدء في تطوير موقع الويب الخاص بك.
2- إنشاء مشروع Django: سنتعلم كيفية إنشاء مشروع Django جديد،
وفهم هيكلية المشروع، وكيفية تنظيم ملفاته.
3- تصميم قاعدة البيانات: سنتعلم كيفية تصميم قاعدة بيانات لموقع الويب الخاص بك
باستخدام Django ORM (Object-Relational Mapper)، وكيفية
إنشاء الجداول والعلاقات بينها.
4- إنشاء النماذج (Models): سنتعلم كيفية إنشاء نماذج (Models) في Django
لتمثيل بيانات موقع الويب الخاص بك، وكيفية استخدامها للتفاعل مع قاعدة البيانات.
5- إنشاء طرق العرض (Views): سنتعلم كيفية إنشاء طرق عرض (Views) في
Django للتعامل مع طلبات المستخدمين، وجلب البيانات من قاعدة البيانات، وعرضها في قوالب HTML.
6- إنشاء القوالب (Templates): سنتعلم كيفية إنشاء قوالب (Templates)
في Django باستخدام HTML و CSS و JavaScript، وكيفية
استخدامها لعرض البيانات بشكل جذاب ومرتب.
7- إدارة المستخدمين: سنتعلم كيفية إدارة المستخدمين في موقع الويب الخاص بك،
وكيفية إنشاء نظام تسجيل دخول وخروج، وتحديد صلاحيات المستخدمين.
8- اختبار موقع الويب: سنتعلم كيفية اختبار موقع الويب الخاص بك باستخدام أدوات
Django للاختبار، والتأكد من أنه يعمل بشكل صحيح.
9- نشر موقع الويب: سنتعلم كيفية نشر موقع الويب الخاص بك على الإنترنت، وجعله متاحًا للجميع.
لماذا تختار Python و Django؟
*Python: لغة برمجة سهلة التعلم وقوية، تتميز بمرونة عالية ومكتبات
واسعة تدعم مختلف مجالات التطوير.
*Django: إطار عمل ويب عالي المستوى، يوفر لك الأدوات والميزات اللازمة
لتطوير مواقع ويب معقدة بكفاءة وسرعة، مثل:
*ORM: نظام إدارة قواعد البيانات سهل الاستخدام، يسمح لك بالتفاعل مع قواعد
البيانات باستخدام Python بدلاً من SQL.
*نظام القوالب: نظام قوالب قوي ومرن، يسمح لك بفصل منطق العمل عن تصميم الواجهة الأمامية.
*الأمان: يوفر Django العديد من الميزات الأمنية المدمجة، التي تساعدك
على حماية موقع الويب الخاص بك من الهجمات الإلكترونية.
متطلبات البدء : - جهاز كمبيوتر يعمل بنظام تشغيل حديث (Windows, macOS, Linux).
- اتصال بالإنترنت لتنزيل الأدوات والمكتبات.
- معرفة أساسية بلغة البرمجة Python (غير ضرورية، ولكنها تساعد).
الخطوات الأساسية لإنشاء موقع ويب باستخدام Python و Django
- تثبيت Python: قم بتنزيل أحدث إصدار من Python من الموقع الرسمي، وقم بتثبيته على جهازك.
- تثبيت Django: استخدم أداة pip لتثبيت Django على جهازك.
- إنشاء مشروع Django: استخدم الأمر django-admin startproject
لإنشاء مشروع Django جديد.
- إنشاء تطبيق Django: استخدم الأمر python manage.py startapp لإنشاء
تطبيق Django جديد داخل مشروعك.
- تصميم قاعدة البيانات: قم بتصميم قاعدة البيانات الخاصة بك، وحدد الجداول والعلاقات بينها.
- إنشاء النماذج (Models): قم بإنشاء نماذج (Models) في Django لتمثيل
بيانات موقع الويب الخاص بك.
- إنشاء طرق العرض (Views): قم بإنشاء طرق عرض (Views) للتعامل مع طلبات المستخدمين،
وجلب البيانات من قاعدة البيانات، وعرضها في قوالب HTML.
- إنشاء القوالب (Templates): قم بإنشاء قوالب (Templates) باستخدام HTML و
CSS و JavaScript لعرض البيانات بشكل جذاب ومرتب.
- تسجيل المسارات (URLs): قم بتسجيل المسارات (URLs) في ملف urls.py لتحديد
كيفية وصول المستخدمين إلى صفحات موقع الويب الخاص بك.
- اختبار موقع الويب: قم باختبار موقع الويب الخاص بك باستخدام أدوات Django للاختبار،
والتأكد من أنه يعمل بشكل صحيح.
- نشر موقع الويب: قم بنشر موقع الويب الخاص بك على الإنترنت، وجعله متاحًا للجميع.
الخطوات الكاملة لإنشاء موقع ويب بسيط باستخدام Python و Django
أقدم لك شرحًا مفصلًا مع الأكواد و
الخطوات الكاملة لإنشاء موقع ويب بسيط باستخدام Python و Django :
* الخطوات الأساسية
1. تثبيت Python
- تنزيل Python: قم بتنزيل أحدث إصدار من Python من الموقع الرسمي:
https://www.python.org/downloads/
- تثبيت Python: اتبع التعليمات لتثبيت Python على نظام التشغيل الخاص بك.
- تأكد من تحديد خيار "Add Python to PATH" أثناء التثبيت.
- التحقق من التثبيت: افتح سطر الأوامر (Command Prompt أو Terminal)
واكتب python --version للتحقق من تثبيت Python بنجاح.
2. تثبيت Django
تفعيل بيئة افتراضية (اختياري ولكن يُنصح به):
- افتح سطر الأوامر وانتقل إلى المجلد الذي ترغب بإنشاء مشروعك فيه.
- اكتب python -m venv myenv لإنشاء بيئة افتراضية باسم "myenv".
قم بتفعيل البيئة الافتراضية:
Windows: myenv\Scripts\activate
macOS/Linux: source myenv/bin/activate
- تثبيت Django: اكتب الأمر التالي في سطر الأوامر لتثبيت Django:
pip install django
3. إنشاء مشروع Django
- إنشاء المشروع: في سطر الأوامر، انتقل إلى المجلد الذي ترغب بإنشاء
مشروعك فيه، ثم اكتب الأمر التالي:
django-admin startproject mysite
- سيتم إنشاء مجلد جديد باسم "mysite" يحتوي على ملفات المشروع.
هيكلية المشروع:
mysite/
├── mysite/
│ ├── __init__.py
│ ├── asgi.py
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
└── manage.py
4. إنشاء تطبيق Django
- إنشاء التطبيق: داخل مجلد "mysite"، اكتب الأمر التالي لإنشاء تطبيق جديد باسم "myapp":
python manage.py startapp myapp
- سيتم إنشاء مجلد جديد باسم "myapp" يحتوي على ملفات التطبيق.
5. تصميم قاعدة البيانات (Models)
- تعديل ملف models.py: داخل مجلد "myapp"، افتح ملف models.py و
أضف تعريفًا للنموذج (Model) الذي يمثل بياناتك.
على سبيل المثال، لإنشاء نموذج للمنتجات:
from django.db import models
class Product(models.Model):
name = models.CharField(max_length=200)
description = models.TextField()
price = models.DecimalField(max_digits=10, decimal_places=2)
def __str__(self):
return self.name
- إنشاء الجداول في قاعدة البيانات: في سطر الأوامر، اكتب الأوامر التالية
لإنشاء الجداول في قاعدة البيانات:
python manage.py makemigrations
python manage.py migrate
6. إنشاء طرق العرض (Views)
- تعديل ملف views.py: داخل مجلد "myapp"، افتح ملف views.py وأضف
تعريفًا للطرق التي تتعامل مع طلبات المستخدمين وتعرض البيانات.
على سبيل المثال، لعرض قائمة بالمنتجات:
from django.shortcuts import render
from .models import Product
def product_list(request):
products = Product.objects.all()
return render(request, 'myapp/product_list.html', {'products': products})
7. إنشاء القوالب (Templates)
- إنشاء مجلد templates: داخل مجلد "myapp"، قم
بإنشاء مجلد جديد باسم "templates".
- إنشاء قالب HTML: داخل مجلد "templates"، قم بإنشاء ملف HTML جديد
باسم "product_list.html" وأضف إليه الكود التالي لعرض قائمة المنتجات:
HTML
<h1>قائمة المنتجات</h1>
<ul>
{% for product in products %}
<li>{{ product.name }} - {{ product.price }}</li>
{% endfor %}
</ul>
8. تسجيل المسارات (URLs)
- تعديل ملف urls.py الرئيسي: داخل مجلد "mysite"، افتح ملف
urls.py وأضف إليه المسار الخاص بتطبيق "myapp":
from django.contrib import admin
from django.urls import path, include
urlpatterns = [
path('admin/', admin.site.urls),
path('products/', include('myapp.urls')),
]
إنشاء ملف urls.py خاص بالتطبيق: داخل مجلد "myapp"، قم بإنشاء
ملف جديد باسم urls.py وأضف إليه المسار الخاص بعرض قائمة المنتجات:
from django.urls import path
from . import views
urlpatterns = [
path('', views.product_list, name='product_list'),
]
9. تشغيل الخادم
- تشغيل الخادم: في سطر الأوامر، داخل مجلد "mysite"، اكتب الأمر التالي لتشغيل الخادم المحلي:
python manage.py runserver
- زيارة الموقع : افتح متصفح الويب الخاص بك وزر العنوان التالي:
http://127.0.0.1:8000/products/
10. نشر الموقع
- اختيار مزود استضافة: اختر مزود استضافة يدعم تشغيل تطبيقات Django مثل
Heroku أو PythonAnywhere أو AWS.
- اتباع تعليمات النشر: اتبع تعليمات مزود الاستضافة لنشر موقعك على الإنترنت.
نصائح لبناء تطبيقات Django عالية الجودة
1- كن حذرا بشأن "التطبيقات"
يتضمن Django هذا المفهوم الخاص بـ "التطبيقات"والتي تم وصفها بشكل غامض في
الوثائق على أنها "حزمة Python توفر مجموعة من الميزات".
في حين أنها منطقية كمكتبات قابلة لإعادة الاستخدام يمكن توصيلها بمشاريع مختلفة،
فإن فائدتها فيما يتعلق بتنظيم كود التطبيق الرئيسي الخاص بك أقل وضوحًا.
هناك بعض الآثار المترتبة على كيفية تعريف "تطبيقاتك" والتي يجب أن تكون على دراية بها.
أكبرها هو أن Django يتتبع عمليات نقل النماذج بشكل منفصل لكل تطبيق.
إذا كان لديك نماذج ربط ForeignKey عبر تطبيقات مختلفة، فسيحاول
نظام نقل Django استنتاج رسم بياني للتبعيات بحيث يتم تشغيل عمليات النقل بالترتيب الصحيح.
لسوء الحظ، هذه الحسابات ليست مثالية ويمكن أن تؤدي إلى بعض الأخطاء أو
حتى التبعيات الدائرية المعقدة، خاصة إذا كان لديك الكثير من التطبيقات.
باختصار، إليك اقتراحاتنا لأي مطور يبدأ مشروع Django:
* إذا كنت لا تفهم حقًا الغرض من التطبيقات، فتجاهلها والتزم بتطبيق واحد للواجهة الخلفية.
لا يزال بإمكانك تنظيم قاعدة بيانات متزايدة من التعليمات البرمجية دون استخدام تطبيقات منفصلة.
* إذا كنت تريد إنشاء تطبيقات منفصلة فسوف تحتاج إلى أن تكون متعمدًا للغاية بشأن كيفية تعريفها.
كن واضحًا للغاية بشأن أي تبعيات بين التطبيقات المختلفة وقللها إلى أدنى حد.
(إذا كنت تخطط للانتقال إلى خدمات مصغرة في المستقبل، يمكنني أن أتخيل أن
"التطبيقات" قد تكون بنية مفيدة لتحديد مقدمات لخدمة مصغرة مستقبلية).
2- تنظيم تطبيقاتك داخل حزمة
بينما نتحدث عن التطبيقات، فلنتحدث قليلاً عن تنظيم الحزمة.
إذا اتبعت البرنامج التعليمي "Getting started" الخاص
بـ Django، manage.py startapp فسيقوم الأمر بإنشاء "تطبيق" في المستوى الأعلى
من دليل المشروع ، على سبيل المثال، يمكن الوصول إلى تطبيق يسمى
foo كـ import foo.models… . ننصحك بشدة بوضع تطبيقاتك
(وأي من أكواد Python الخاصة بك) في حزمة Python، أي الحزمة التي تم إنشاؤها
باستخدام django-admin startproject.
في مثال البرنامج التعليمي الخاص بـ Django، بدلاً من:
mysite/
mysite/
__init__.py
polls/
__init__.py
نحن نقترح:
mysite/
mysite/
__init__.py
polls/
__init__.py
هذا تغيير بسيط ودقيق، ولكنه يمنع تعارضات مساحة الأسماء بين تطبيقك
ومكتبات Python التابعة لجهات خارجية.
في Python، تنتقل وحدات المستوى الأعلى إلى مساحة أسماء عالمية وتحتاج إلى تسمية فريدة.
على سبيل المثال، مكتبة Python الخاصة بالبائع الذي استخدمناه،
Segment، تسمى بالفعل analytics. إذا كان لدينا analytics تطبيق محدد كوحدة
مستوى أعلى، فلن تكون هناك طريقة للتمييز بين الحزمتين في الكود الخاص بك.
3- قم بتسمية جداول قاعدة البيانات الخاصة بك بشكل صريح
إن قاعدة البيانات الخاصة بك أكثر أهمية، وأطول عمرًا، وأصعب تغييرًا بعد
وقوع الحدث من تطبيقك. ومع العلم بذلك، فمن المنطقي أن تكون حريصًا
للغاية بشأن كيفية تصميم مخطط قاعدة البيانات الخاصة بك، بدلاً من
السماح لإطار عمل الويب باتخاذ هذه القرارات نيابةً عنك.
على الرغم من أنك تتحكم بشكل كبير في مخطط قاعدة البيانات في Django،
فهناك بعض الأشياء التي يتعامل معها بشكل افتراضي والتي يجب أن تعرفها.
على سبيل المثال، يقوم Django تلقائيًا بإنشاء اسم جدول لنماذجك، باستخدام النمط <app_name>_<model_name_lowercased>.
بدلاً من الاعتماد على هذه الأسماء المولدة تلقائيًا، يجب أن تفكر في تحديد اتفاقية
التسمية الخاصة بك وتسمية جميع جداولك يدويًا، باستخدام Meta.db_table.
class Foo(Model):
class Meta:
db_table = 'foo'
الشيء الآخر الذي يجب الانتباه إليه هو ManyToManyFields.
يجعل Django من السهل إنشاء علاقات متعددة إلى متعددة باستخدام هذا
الحقل وسيقوم بإنشاء جدول الانضمام بأسماء الجداول والأعمدة التي تم إنشاؤها تلقائيًا.
بدلاً من القيام بذلك، نقترح عليك بشدة إنشاء جداول الانضمام وتسميتها يدويًا دائمًا
(باستخدام through سوف يجعل ذلك الوصول إلى الجدول مباشرةً أسهل كثيرًا،
وبصراحة، وجدنا أنه من المزعج أن يكون لديك جداول مخفية.
قد تبدو هذه تفاصيل ثانوية، لكن فصل تسمية قاعدة البيانات عن تفاصيل
تنفيذ Django فكرة جيدة لأنه ستكون هناك أشياء أخرى تلمس بياناتك
إلى جانب Django ORM، مثل مستودعات البيانات. يتيح لك هذا أيضًا
إعادة تسمية فئات النموذج الخاصة بك لاحقًا إذا غيرت رأيك.
أخيرًا، سيؤدي ذلك إلى تبسيط أشياء مثل تقسيم الجداول إلى خدمات
منفصلة أو الانتقال إلى إطار عمل ويب مختلف.
4- تجنب GenericForeignKey
إذا كان بوسعك تجنب ذلك، فتجنب استخدام GenericForeignKey.
ستفقد ميزات استعلام قاعدة البيانات مثل joins ( select_related)
وميزات سلامة البيانات مثل قيود المفتاح الخارجي والحذف المتتالي.
عادةً ما يكون استخدام الجداول المنفصلة حلاً أفضل، ويمكنك الاستفادة من
النماذج الأساسية المجردة إذا كنت تبحث عن إعادة استخدام التعليمات البرمجية.
مع ذلك، هناك مواقف حيث لا يزال من المفيد وجود جدول يمكنه الإشارة إلى جداول مختلفة.
إذا كان الأمر كذلك، فسيكون من الأفضل أن تقوم بتنفيذه بنفسك ولن
يكون الأمر صعبًا (تحتاج فقط إلى عمودين، أحدهما لمعرف الكائن والآخر لتحديد النوع).
أحد الأشياء التي لا نحبها في GenericForeignKey هي أنها تعتمد على إطار
عمل ContentTypes الخاص بـ Django، والذي يخزن معرفات الجداول
في جدول تعيين يسمى django_contenttypes.
هذا الجدول ليس ممتعًا جدًا للتعامل معه. بالنسبة للمبتدئين، فإنه يستخدم
اسم التطبيق الخاص بك ( app_label) وفئة نموذج Python ( model)
كأعمدة لتعيين نموذج Django إلى معرف عدد صحيح، والذي يتم تخزينه
بعد ذلك داخل الجدول باستخدام GFK. إذا قمت بنقل النماذج بين التطبيقات أو
إعادة تسمية تطبيقاتك، فسيتعين عليك إجراء بعض التصحيحات اليدوية على هذا الجدول.
والأهم من ذلك، أن وجود جدول مشترك يحمل تعيين GFK هذا سيعقد الأمور
بشكل كبير إذا كنت تريد نقل جداولك إلى خدمات وقواعد بيانات منفصلة.
على غرار القسم السابق حول تسمية جداولك صراحةً - يجب أن تمتلك وتحدد
معرفات الجدول الخاصة بك أيضًا. سواء كنت تريد استخدام عدد صحيح أو سلسلة
أو أي شيء آخر للقيام بذلك، فإن أيًا من هذه أفضل من الاعتماد على معرف عشوائي محدد في جدول عشوائي.
5- الحفاظ على سلامة الهجرة Keep migrations safe
إذا كنت تستخدم Django 1.7 أو إصدارًا أحدث وتستخدم قاعدة بيانات علائقية،
فمن المحتمل أنك تستخدم نظام الترحيل الخاص بـ Django لإدارة مخططك وترحيله.
ومع بدء التشغيل على نطاق واسع، هناك بعض الفروق الدقيقة المهمة التي
يجب مراعاتها حول استخدام عمليات ترحيل Django.
أولاً وقبل كل شيء، ستحتاج إلى التأكد من أن عمليات الترحيل الخاصة بك آمنة، بمعنى أنها لن
تتسبب في توقف الخدمة عند تطبيقها. لنفترض أن عملية النشر الخاصة بك تتضمن
الاتصال manage.py migrate تلقائيًا قبل نشر أحدث التعليمات البرمجية
على خوادم التطبيقات الخاصة بك. ستكون عملية مثل إضافة عمود جديد آمنة.
ولكن لا ينبغي أن يكون من المستغرب أن يؤدي حذف عمود إلى كسر الأشياء،
حيث سيظل الكود الموجود يشير إلى العمود غير الموجود.
حتى إذا لم تكن هناك أسطر من التعليمات البرمجية تشير إلى الحقل المحذوف، فعندما يقوم
Django بجلب كائن (على سبيل المثال (..)Model.objects.get،
تحت الغطاء، فإنه يقوم بإجراء SELECT على كل عمود محدد في النموذج.
ونتيجة لذلك، فإن أي وصول Django ORM إلى هذا الجدول سيثير استثناءً.
يمكنك تجنب هذه المشكلة من خلال التأكد من تشغيل عمليات الترحيل بعد نشر الكود،
ولكن هذا يعني أن عمليات النشر يجب أن تكون يدوية بعض الشيء.
قد يصبح الأمر صعبًا إذا قام المطورون بتنفيذ عمليات ترحيل متعددة قبل النشر.
هناك حل آخر يتمثل في تحويل هذه الترحيلات الخطيرة وغيرها إلى عمليات ترحيل "بدون عمليات"،
من خلال جعل عمليات الترحيل عمليات "حالة" بحتة. ستحتاج بعد ذلك إلى تنفيذ العمليات DROPبعد النشر.
class Migration(migrations.Migration):
state_operations = [ORIGINAL_MIGRATIONS]
operations = migrations.SeparateDatabaseAndState(
state_operations=state_operations
)
بالطبع، لا يعد إسقاط الأعمدة والجداول العملية الوحيدة التي يجب الانتباه إليها.
إذا كانت لديك قاعدة بيانات إنتاجية كبيرة، فهناك العديد من العمليات غير الآمنة التي قد
تؤدي إلى قفل قاعدة البيانات أو الجداول لديك وتؤدي إلى توقف التشغيل.
تعتمد الأنواع المحددة من العمليات على نوع SQL الذي تستخدمه.
على سبيل المثال، مع PostgreSQL، قد يكون إضافة أعمدة بفهرس أو
أعمدة غير قابلة للإلغاء إلى جدول كبير أمرًا خطيرًا. إليك مقال جيد جدًا
من BrainTree يلخص بعض عمليات الترحيل الخطيرة على PostgreSQL.
6- منع التكدس Squash your migrations
مع تطور مشروعك وتراكم المزيد والمزيد من عمليات الترحيل، ستستغرق هذه العمليات وقتًا
أطول وأطول. من حيث التصميم، يحتاج Django إلى تشغيل كل عملية ترحيل تدريجيًا بدءًا من أول
عملية ترحيل من أجل إنشاء حالته الداخلية لمخطط قاعدة البيانات. لن يؤدي هذا إلى إبطاء عمليات
النشر في الإنتاج فحسب، بل سيضطر المطورون أيضًا إلى الانتظار عند إعداد قاعدة بيانات التطوير
المحلية الخاصة بهم في البداية. إذا كان لديك قواعد بيانات متعددة، فستستغرق هذه العملية وقتًا أطول،
لأن Django سيشغل جميع عمليات الترحيل على كل قاعدة بيانات على حدة،
بغض النظر عما إذا كانت عملية الترحيل تؤثر على تلك القاعدة البيانات أم لا.
باستثناء تجنب عمليات نقل البيانات باستخدام Django بالكامل، فإن أفضل حل توصلنا إليه هو
إجراء بعض التنظيف الدوري و"سحق" عمليات النقل. أحد الخيارات هو تجربة ميزة السحق المضمنة
في Django. خيار آخر، نجح معنا بشكل جيد، هو القيام بذلك يدويًا. إسقاط كل شيء
في الجدول django_migrations، وحذف ملفات النقل الحالية، وتشغيل الأمر
manage.py makemigrationsلإنشاء عمليات نقل بيانات جديدة وموحدة.
7- تقليل احتكاك الهجرة Reduce migration friction
إذا كان هناك عشرات المطورين يعملون على نفس قاعدة بيانات Django، فقد تواجه حالات تسابق
متكررة مع الدمج في عمليات نقل قاعدة البيانات. على سبيل المثال، ضع في اعتبارك سيناريو
حيث يبدو سجل النقل الحالي على الجهاز الرئيسي على النحو التالي:
0001_ a
0002_ b
الآن، لنفترض أن المهندس أ ينشئ عملية هجرة 0003_cعلى فرعه المحلي، ولكن قبل أن يتمكن من دمجه،
يصل المهندس ب إلى هناك أولاً ويتحقق من عملية الهجرة 0003_d. إذا دمج المهندس أ فرعه الآن،
فسيواجه أي شخص يحاول تشغيل عمليات الهجرة بعد سحب أحدث التعليمات البرمجية الخطأ
"تم اكتشاف عمليات هجرة متضاربة؛ عقد أوراق متعددة في رسم بياني للهجرة:
. " (0003_c، 0003_d)
على أقل تقدير، يؤدي هذا إلى ضرورة تحويل عمليات الترحيل إلى خطية يدويًا أو
إنشاء ترحيل دمج، مما يتسبب في حدوث احتكاك في عملية تطوير الفريق. يناقش فريق هندسة
Zenefits هذه المشكلة بمزيد من التفصيل في منشور مدونة ، والذي استمددنا منه الإلهام لتحسين هذا الأمر.
في أقل من اثني عشر سطرًا من التعليمات البرمجية، تمكنا من حل شكل أكثر عمومية
لهذه المشكلة في حالة وجود تطبيقات Django متعددة . لقد فعلنا ذلك من خلال تجاوز
handle()طريقة الأمر الخاص بنا makemigrationsلإنشاء بيان هجرة متعدد التطبيقات:
def handle(self, *app_labels, **options):
# Generate a migrations manifest with latest migration on each app
super(Command, self).handle(*app_labels, **options)
loader = MigrationLoader(None, ignore_no_migrations=True)
apps = sorted(loader.migrated_apps)
graph = loader.graph
with open('latest_migrations.manifest', 'w') as f:
for app_name in apps:
leaf_nodes = graph.leaf_nodes(app_name)
if len(leaf_nodes) != 1:
raise Exception('App {} has multiple leaf migrations!'.format(app_name))
f.write('{}: {}\n'.format(app_name, leaf_nodes[0][1]))
بتطبيق هذا على المثال أعلاه، سيحتوي ملف البيان على إدخال واحد
doordash: 0002_b لتطبيقنا. إذا قمنا بإنشاء ملف ترحيل جديد 0003_c من
HEAD، فسيتم تطبيق الاختلاف في ملف البيان بشكل نظيف ويمكن دمجه كما هو:
- doordash: 0002_b
+ doordash: 0003_c
ومع ذلك، إذا كانت عمليات الترحيل قديمة، مثل إذا كان المهندس لديه
0001_a محليًا فقط ويقوم بإنشاء عملية ترحيل جديدة 0002_d،
فلن يتم تطبيق ملف البيان diff بشكل نظيف وبالتالي سيعلن Github عن وجود تعارضات دمج:
- doordash: 0001_a
+ doordash: 0002_d
سيكون المهندس مسؤولاً بعد ذلك عن حل النزاع قبل أن يسمح موقع Github
بدمج طلب السحب. إذا كان لديك اختبارات تكامل حيث يتم حظر عمليات
دمج التعليمات البرمجية (وهو ما يجب أن تفعله أي شركة بهذا الحجم)،
فهذا أيضًا دافع آخر للحفاظ على مجموعة الاختبارات سريعة!
8- تجنب العارضات البدينات fat model
يروج Django لنمط "النموذج السمين fat model" حيث تضع الجزء الأكبر
من منطق عملك داخل طرق النموذج. في حين أن هذا هو ما استخدمناه في البداية،
ويمكن أن يكون ملائمًا جدًا، إلا أننا أدركنا أنه لا يتوسع بشكل جيد.
بمرور الوقت، تصبح فئات النموذج متضخمة بالطرق وتصبح طويلة للغاية ويصعب قراءتها.
تعد Mixins إحدى الطرق للتخفيف من التعقيد قليلاً، لكنها لا تبدو وكأنها حل مثالي.
قد يكون هذا النمط غريبًا بعض الشيء إذا كان لديك منطق لا يحتاج حقًا إلى العمل على نموذج
كامل تم جلبه من قاعدة البيانات، بل يحتاج فقط إلى المفتاح الأساسي أو تمثيل مبسط مخزّن
في ذاكرة التخزين المؤقت. بالإضافة إلى ذلك، إذا كنت ترغب في الانتقال من Django ORM، فإن
ربط منطقك بالنماذج من شأنه أن يعقد هذا الجهد.
مع ذلك، فإن النية الحقيقية وراء هذا النمط هي الحفاظ على واجهة
برمجة التطبيقات/العرض/وحدة التحكم خفيفة الوزن وخالية من المنطق المفرط،
وهو أمر نوصي به بشدة. إن وجود منطق داخل طرق النموذج هو شر أقل، ولكن قد ترغب في
التفكير في الحفاظ على النماذج خفيفة الوزن وتركيزها على طبقة البيانات.
لجعل هذا يعمل، ستحتاج إلى معرفة نمط جديد ووضع منطق عملك في طبقة ما بين طبقة
البيانات وطبقة واجهة برمجة التطبيقات/العرض.
9- كن حذرا مع الإشارات
يمكن أن يكون إطار عمل إشارات Django مفيدًا لفصل
الأحداث عن الإجراءات، ولكن هناك حالة استخدام واحدة يمكن أن
تكون مزعجة وهي pre/post_save الإشارات. يمكن أن تكون مفيدة
لأشياء صغيرة (على سبيل المثال التحقق من وقت إبطال ذاكرة التخزين المؤقت)
ولكن وضع الكثير من المنطق في الإشارات يمكن أن يجعل تتبع وقراءة تدفق البرنامج أمرًا صعبًا.
إن تمرير الوسائط أو المعلومات المخصصة عبر إشارة أمر غير ممكن حقًا.
كما أنه من الصعب جدًا، دون استخدام بعض الاختراقات، تعطيل إشارة من الإطلاق في
ظروف معينة (على سبيل المثال إذا كنت تريد تحديث بعض النماذج بشكل جماعي دون تشغيل إشارات باهظة الثمن).
نصيحتنا لك هي الحد من استخدامك لهذه الإشارات، وإذا كنت تستخدمها،
فتجنب وضع أي منطق غير بسيط ورخيص بداخلها.
يجب عليك أيضًا الاحتفاظ بهذه الإشارات منظمة في مكان يمكن التنبؤ به ومتسق
(على سبيل المثال بالقرب من المكان الذي يتم فيه تعريف النماذج)، لتسهيل قراءة الكود الخاص بك.
10- تجنب استخدام ORM كواجهة رئيسية لبياناتك
إذا كنت تقوم بإنشاء وتحديث كائنات قاعدة البيانات مباشرةً من أجزاء عديدة
من قاعدة التعليمات البرمجية الخاصة بك باستخدام استدعاءات واجهة
Django ORM ( Model.objects.create()أو Model.save())،
فقد ترغب في إعادة النظر في هذا النهج. لقد وجدنا أن استخدام ORM
كواجهة أساسية لتعديل البيانات له بعض العيوب.
المشكلة الرئيسية هي أنه لا توجد طريقة واضحة لأداء الإجراءات الشائعة عند إنشاء نموذج أو تحديثه.
افترض أنه في كل مرة يتم فيها إنشاء ModelA، فأنت تريد حقًا إنشاء
مثيل لـ ModelB أيضًا. أو تريد اكتشاف متى تغير حقل معين عن قيمته السابقة.
بصرف النظر عن الإشارات، فإن الحل الوحيد المتاح لك هو تحميل الكثير من المنطق
في ()Model.save، والذي يمكن أن يصبح صعبًا للغاية ومحرجًا.
أحد الحلول لهذه المشكلة هو إنشاء نمط تقوم من خلاله بتوجيه جميع
عمليات قاعدة البيانات المهمة (إنشاء/تحديث/حذف) create/update/delete عبر نوع
ما من الواجهة البسيطة التي تغلف طبقة ORM. يمنحك هذا نقاط
دخول واضحة لإضافة منطق إضافي قبل أو بعد أحداث قاعدة البيانات.
بالإضافة إلى ذلك، فإن فصل كود التطبيق الخاص بك قليلاً عن واجهة النموذج سيمنحك
المرونة اللازمة للتخلي عن Django ORM في المستقبل.
11- لا تقم بتخزين نماذج Django مؤقتًا
إذا كنت تعمل على توسيع نطاق تطبيقك، فمن المحتمل أنك تستفيد من حل
التخزين المؤقت مثل Memcached أو Redis لتقليل استعلامات قاعدة البيانات.
ورغم أنه قد يكون من المغري تخزين حالات نموذج Django، أو حتى
نتائج مجموعات استعلامات كاملة، إلا أن هناك بعض التحذيرات التي يجب أن تكون على دراية بها.
إذا قمت بنقل مخططك (إضافة/تغيير/حذف حقول من النموذج)
add/change/delete fields from your model، فإن
Django في الواقع لا يتعامل مع هذا الأمر بسلاسة عند التعامل مع المثيلات المخزنة مؤقتًا.
إذا حاول Django قراءة مثيل نموذج تم كتابته إلى ذاكرة التخزين المؤقت من إصدار
سابق من المخطط، فسوف يموت تقريبًا. تحت الغطاء، يقوم بإلغاء تسلسل
كائن مخلل من واجهة ذاكرة التخزين المؤقت الخلفية، لكن هذا الكائن سيكون
غير متوافق مع أحدث التعليمات البرمجية. هذا أكثر من مجرد تفاصيل تنفيذ Django المؤسفة من أي شيء آخر.
يمكنك ببساطة قبول وجود بعض الاستثناءات بعد النشر باستخدام ترحيل النموذج، والحد
من الضرر عن طريق تعيين TTLs قصيرة بشكل معقول للتخزين المؤقت.
والأفضل من ذلك، تجنب تخزين النماذج مؤقتًا كقاعدة عامة. بدلاً من ذلك، قم فقط
بتخزين المفاتيح الأساسية، وابحث عن الكائنات من قاعدة البيانات.
(عادةً، عمليات البحث عن المفاتيح الأساسية رخيصة جدًا. إن استعلامات
SELECT للعثور على هذه المعرفات هي المكلفة).
بالانتقال إلى خطوة أبعد لتجنب إصابات قاعدة البيانات تمامًا، لا يزال بإمكانك
تخزين نماذج Django بأمان إذا كنت تحتفظ بنسخة واحدة مخزنة مؤقتًا من مثيل النموذج.
بعد ذلك، من السهل جدًا إبطال صلاحية هذا التخزين المؤقت عند إجراء تغييرات
على مخطط النموذج.
* خاتمة
إن Django هو بالتأكيد إطار عمل قوي ومليء بالميزات لبدء تشغيل
الخدمة الخلفية الخاصة بك، ولكن هناك تفاصيل دقيقة يجب الانتباه إليها
والتي يمكن أن توفر لك الصداع في المستقبل. إن تحديد تطبيقات Django
بعناية وتنفيذ تنظيم جيد للكود مقدمًا سيساعدك على تجنب عمل إعادة الهيكلة
غير الضروري لاحقًا. وفي الوقت نفسه، من خلال السيطرة الكاملة على
مخطط قاعدة البيانات الخاصة بك والحرص على كيفية استخدام ميزات Django مثل
GenericForeignKey وORM، يمكنك التأكد من أنك لست مرتبطًا كثيرًا
بالإطار والانتقال إلى تقنيات أو هياكل أخرى في المستقبل.
من خلال التفكير في هذه الأمور، يمكنك الحفاظ على المرونة اللازمة للتطور
وتوسيع نطاق عملك الخلفي في المستقبل. نأمل أن تساعدك بعض الأشياء التي
تعلمناها حول استخدام Django في بناء تطبيقاتك الخاصة!
هذا مثال بسيط، ويمكنك تطويره وإضافة المزيد من الميزات والصفحات.
هذا الدليل موجه إلى جميع الراغبين في تعلم تطوير الويب باستخدام Python و Django،
سواء كانوا مبتدئين أو لديهم خبرة سابقة في البرمجة.
الخلاصة Python و Django هما الأدوات المثالية لإنشاء مواقع ويب ديناميكية وتفاعلية.
باستخدام هذا الدليل الشامل، يمكنك تعلم كيفية إنشاء موقع ويب خاص بك من البداية إلى الاحتراف.
نتمنى لك التوفيق في رحلتك لتعلم تطوير الويب باستخدام Python و Django!
