شرح بنية MVC وMVT في Django
عندما تبدأ رحلتك مع Django، قد تسمع كثيرًا عن بنية MVT، وقد تكون درست من قبل بنية MVC في لغات وأطر عمل أخرى. في البداية قد يبدو الأمر وكأننا نتحدث عن نفس الفكرة بأسماء مختلفة، لكن الحقيقة أجمل من ذلك قليلًا: Django لا يكتفي بتقسيم المشروع إلى أجزاء، بل يعلّمك كيف تفصل المسؤوليات بطريقة تجعل الكود أكثر وضوحًا، وأسهل في التعديل، وأقل عرضة للفوضى مع نمو المشروع. وهذا بالضبط ما تحتاجه عندما يتحول مشروع صغير من صفحة أو صفحتين إلى تطبيق حقيقي فيه مستخدمون، بيانات، صلاحيات، ونماذج معقدة.
في هذا المقال سنأخذك في جولة هادئة ومفصلة لفهم MVC وMVT، وكيف يترجمهما Django عمليًا، ولماذا تعتمد كثير من التطبيقات الناجحة على هذا النوع من التنظيم. سنبني الفكرة خطوة خطوة، مع أمثلة برمجية واضحة، وبأسلوب قريب من الواقع حتى لا تبقى المفاهيم مجرد أسماء نظرية محفوظة.
لماذا نحتاج أصلًا إلى بنية منظمة مثل MVC أو MVT؟
تخيل أنك تعمل على مشروع واحد وكل شيء موجود في ملف واحد: منطق قاعدة البيانات، عرض الصفحة، التحقق من صحة البيانات، التعامل مع الطلبات، وحتى التنسيق. في البداية قد يبدو الأمر سريعًا، لكن بعد أيام قليلة ستبدأ المشاكل. ستجد نفسك تخاف من تعديل سطر واحد لأنك لا تعرف ما الذي قد ينكسر. ومع مرور الوقت يصبح التعديل البسيط معركة.
هنا تظهر قيمة البنية المنظمة. الفكرة ليست أن نضع "قواعد" نظرية فقط، بل أن نوزع المسؤوليات بحيث يعرف كل جزء ماذا يفعل. القاعدة الذهبية هنا بسيطة: كل جزء من التطبيق يجب أن يؤدي وظيفة محددة وواضحة. هذا ما يجعل المشروع قابلًا للصيانة، وقابلًا للتوسعة، وسهل الفهم لأي مطور جديد يدخل إليه بعدك.
ما هي MVC؟
MVC اختصار لـ:
Model
View
Controller
هذه البنية ظهرت في عالم تطوير البرمجيات لتقسيم التطبيق إلى ثلاث طبقات أساسية:
Model يهتم بالبيانات والمنطق المرتبط بها.
View يهتم بما يراه المستخدم.
Controller يستقبل الطلبات ويقرر ما الذي يجب فعله ثم ينسق بين النموذج والعرض.
بصيغة أبسط، يمكنك أن تتخيل MVC كالتالي: المستخدم يتفاعل مع الواجهة، الواجهة ترسل الحدث إلى المتحكم، المتحكم يتحدث مع النموذج، ثم يعيد النتيجة إلى الواجهة.
مثال ذهني بسيط على MVC
عندما يضغط المستخدم زر "إرسال" في نموذج تسجيل:
View يعرض النموذج للمستخدم.
Controller يستقبل بيانات الإرسال.
Model يتحقق من البيانات ويخزنها في قاعدة البيانات.
View تعود لتعرض رسالة نجاح أو خطأ.
هذه الفكرة واضحة جدًا، ولذلك أصبحت MVC شائعة في كثير من الأطر والتقنيات.
ما هي MVT في Django؟
Django يستخدم بنية تسمى MVT، وهي اختصار لـ:
Model
View
Template
قد يبدو الاسم مختلفًا، لكن الجوهر قريب جدًا من MVC. الفرق الأساسي هو أن Django يغير توزيع الأدوار قليلًا:
Model يبقى مسؤولًا عن البيانات.
View في Django لا تكون واجهة العرض، بل تكون الجهة التي تستقبل الطلبات وتنفذ المنطق البرمجي.
Template هو الجزء الذي يعرض الشكل النهائي للمستخدم.
وهنا يحدث الالتباس عند الكثير من المبتدئين: في Django، كلمة View لا تعني صفحة HTML كما قد تتوقع من MVC، بل تعني الوظيفة أو المنطق الذي يقرر ماذا سيُعرض للمستخدم.
أين ذهب Controller في Django؟
في Django لا يوجد Controller باسم صريح كما في MVC التقليدية. لكن يمكنك اعتبار أن Django نفسه، مع نظام التوجيه URL dispatcher وبعض المكونات الداخلية، يقوم بدور قريب من المتحكم. أي أن Django يمرر الطلب إلى الـ view المناسب، ثم ينسق الرد ويعيده للمتصفح.
إذن يمكننا القول بشكل عملي:
Model = البيانات
View = منطق الطلب
Template = العرض
ومع أن هذا ليس نفس MVC حرفيًا، إلا أنه قريب جدًا في الفلسفة.
الفرق الحقيقي بين MVC وMVT
الفرق ليس في الفكرة الأساسية، بل في توزيع الأدوار.
في MVC:
Controller يستقبل الطلب
View يعرض الواجهة
Model يدير البيانات
في Django MVT:
View يستقبل الطلب ويعالج المنطق
Template يعرض الواجهة
Model يدير البيانات
إذن Django نقل جزء "العرض" إلى Template، وترك View للمنطق. هذا التغيير يجعل الأمور أكثر وضوحًا داخل Django، لأن القوالب Templates مخصصة لعرض HTML، بينما Views مخصصة لكتابة Python logic.
تشبيه بسيط جدًا
تخيل مطعمًا:
Model هو المطبخ والمخزون والوصفات.
View في Django هو النادل الذي يستقبل الطلب ويقرر ماذا يطلب من المطبخ.
Template هو الطبق النهائي الذي يراه الزبون.
وفي MVC التقليدي، قد يكون تقسيم الأدوار مختلفًا قليلًا، لكن المطعم نفسه يبقى هو المطعم.
كيف يفكر Django داخليًا؟
عندما يطلب المستخدم صفحة مثل:
https://example.com/books/
فإن Django يمر بعدة مراحل:
يستقبل الطلب.
يبحث في ملف urls.py عن المسار المناسب.
يرسل الطلب إلى view محدد.
تقوم الـ view بالتعامل مع البيانات أو المنطق.
قد تستدعي الـ view Model لجلب البيانات من قاعدة البيانات.
ترسل البيانات إلى Template.
يُعاد HTML النهائي إلى المستخدم.
هذه السلسلة هي القلب الحقيقي لفهم Django. من لا يفهمها جيدًا قد يجد نفسه يكتب كودًا يعمل، لكنه غير منظم، أو يصعب إصلاحه لاحقًا.
مثال عملي بسيط على بنية Django
لنفرض أننا نريد بناء تطبيق بسيط لعرض الكتب.
هيكل المشروع
myproject/
│
├── myproject/
│ ├── settings.py
│ ├── urls.py
│ └── wsgi.py
│
├── books/
│ ├── models.py
│ ├── views.py
│ ├── urls.py
│ ├── templates/
│ │ └── books/
│ │ └── list.html
│ └── admin.py
│
└── manage.py
هذا التقسيم ليس فقط شكليًا، بل هو ترجمة عملية لفكرة الفصل بين المسؤوليات.
نموذج البيانات: Model
from django.db import models
class Book(models.Model):
title = models.CharField(max_length=200)
author = models.CharField(max_length=100)
published_at = models.DateField()
description = models.TextField(blank=True)
def __str__(self):
return self.title
هنا قمنا بتعريف نموذج كتاب. هذا النموذج لا يهتم بكيفية عرض الكتاب في الصفحة، ولا بمن سيشاهده. كل ما يفعله هو وصف البيانات وكيفية تخزينها.
الـ View
from django.shortcuts import render
from .models import Book
def book_list(request):
books = Book.objects.all()
return render(request, 'books/list.html', {'books': books})
هذه الـ view تستقبل الطلب، تجلب جميع الكتب، ثم ترسلها إلى القالب المناسب. لاحظ أنها لا تطبع HTML مباشرة، ولا تتعامل مع قاعدة البيانات في صورة فوضوية، بل تجمع البيانات وتعيدها بشكل منظم.
الـ Template
<!DOCTYPE html>
<html lang="ar">
<head>
<meta charset="UTF-8">
<title>قائمة الكتب</title>
</head>
<body>
<h1>قائمة الكتب</h1>
<ul>
{% for book in books %}
<li>
<strong>{{ book.title }}</strong> -
{{ book.author }} -
{{ book.published_at }}
</li>
{% empty %}
<li>لا توجد كتب حاليًا.</li>
{% endfor %}
</ul>
</body>
</html>
هذا هو العرض الذي يراه المستخدم. القالب لا يحتوي منطقًا ثقيلًا، ولا يجب أن يتحول إلى مكان لكتابة الحسابات المعقدة. وظيفته الأساسية هي العرض.
ملف الروابط URL
from django.urls import path
from .views import book_list
urlpatterns = [
path('books/', book_list, name='book_list'),
]
هنا نربط المسار بالـ view المناسبة. وهذا جزء مهم جدًا من فصل المسؤوليات داخل Django.
كيف ترتبط الطبقات الثلاث في Django؟
لفهم Django بشكل عميق، يجب أن ترى العلاقة بين الطبقات الثلاث كما لو أنها دائرة متكاملة:
الطلب Request يدخل من المتصفح.
URL routing يحدد الوجهة.
View تستقبل الطلب وتقرر ماذا تفعل.
Model يوفّر البيانات أو يعدّلها.
Template يحول البيانات إلى شكل مفهوم للمستخدم.
Response يعود إلى المتصفح.
هذا الترابط هو الذي يجعل Django قويًا. إنه لا يجبرك على كتابة كل شيء في مكان واحد، بل يوزع المهام بشكل طبيعي.
لماذا يفضّل الكثيرون Django رغم أن MVC مشهور جدًا؟
لأن Django يمنحك وضوحًا عمليًا أكثر من النقاشات النظرية. في الواقع، أغلب المطورين لا يهمهم الاسم بقدر ما يهمهم ما الذي يفعله كل جزء. Django يقدّم طريقة متماسكة:
النماذج للبيانات
الـ views للمنطق
الـ templates للعرض
وهذا التقسيم يجعل التعامل مع المشاريع الكبيرة أسهل كثيرًا. كما أنه يساعد الفرق البرمجية على العمل معًا دون أن يتداخل الجميع في نفس الملف أو نفس الوظيفة.
أين يقع المنطق التجاري Business Logic؟
هذا سؤال مهم جدًا، لأن كثيرًا من المبتدئين يضعون المنطق في المكان الخطأ. في Django لديك أكثر من خيار، لكن القاعدة الجيدة هي:
ضع ما يتعلق بالبيانات داخل Model عندما يكون منطقيًا ومناسبًا.
ضع منطق التعامل مع الطلبات داخل View.
لا تكدّس القوالب بمنطق معقد.
مثال: إذا كنت تريد حساب سعر بعد خصم معين، فربما يكون من الأفضل وضع الحساب في Model أو في دالة مساعدة خارجية، وليس داخل الـ template.
مثال على دالة داخل Model
from django.db import models
class Product(models.Model):
name = models.CharField(max_length=150)
price = models.DecimalField(max_digits=10, decimal_places=2)
discount_percent = models.PositiveIntegerField(default=0)
def final_price(self):
discount = self.price * self.discount_percent / 100
return self.price - discount
هنا أصبح من السهل استخدام السعر النهائي من أي مكان داخل التطبيق، بدل تكرار الحساب في كل مرة.
هل يجب أن تكون الـ View طويلة؟
لا.
هذه نقطة مهمة جدًا.
الـ view الجيدة تكون مختصرة وواضحة. إذا بدأت تشعر أن الـ view أصبحت طويلة جدًا وتقوم بأكثر من وظيفة، فغالبًا هذا مؤشر على أن الكود يحتاج إعادة تنظيم. يمكنك استخراج أجزاء من المنطق إلى:
services
helpers
forms
model methods
custom managers
مثال على view أبسط:
from django.shortcuts import render, get_object_or_404
from .models import Book
def book_detail(request, book_id):
book = get_object_or_404(Book, id=book_id)
return render(request, 'books/detail.html', {'book': book})
هنا الـ view واضحة جدًا: تجلب كتابًا، ثم تعرضه.
الفرق بين Model وForm وTemplate وView في الحياة الواقعية
الكثير يخلط بين هذه المفاهيم. لذلك لنوضحها بعبارة بشرية بسيطة:
Model هو شكل البيانات داخل قاعدة البيانات.
Form هو وسيلة إدخال البيانات والتحقق منها.
View هو العقل الذي يستقبل الطلب ويتخذ القرار.
Template هو الواجهة التي يراها المستخدم.
عندما يرسل المستخدم نموذجًا لإضافة كتاب، فإن الـ Form يتأكد من صحة البيانات، والـ View يقرر ماذا يفعل بها، وModel يحفظها، وTemplate يعرض النتيجة.
مثال إضافة كتاب
forms.py
from django import forms
from .models import Book
class BookForm(forms.ModelForm):
class Meta:
model = Book
fields = ['title', 'author', 'published_at', 'description']
views.py
from django.shortcuts import render, redirect
from .forms import BookForm
def book_create(request):
if request.method == 'POST':
form = BookForm(request.POST)
if form.is_valid():
form.save()
return redirect('book_list')
else:
form = BookForm()
return render(request, 'books/create.html', {'form': form})
create.html
<!DOCTYPE html>
<html lang="ar">
<head>
<meta charset="UTF-8">
<title>إضافة كتاب</title>
</head>
<body>
<h1>إضافة كتاب جديد</h1>
<form method="post">
{% csrf_token %}
{{ form.as_p }}
<button type="submit">حفظ</button>
</form>
</body>
</html>
لاحظ كيف تم توزيع العمل بشكل جميل. كل جزء يعرف دوره جيدًا، وهذا يقلل الأخطاء ويجعل التطوير اللاحق أكثر راحة.
لماذا تعتبر Templates مهمة جدًا في Django؟
لأن المستخدم لا يتفاعل مع Model مباشرة، ولا مع View ككود Python، بل يتفاعل مع واجهة نهائية. وهنا يأتي دور القوالب Templates. القالب هو المكان الذي تُعرض فيه البيانات بطريقة جميلة ومفهومة.
لكن هناك مبدأ ذهبي: القالب ليس مكانًا للمنطق الثقيل.
يمكنك استخدامه للعروض الشرطية البسيطة والتكرار، لكن لا تجعله يتحول إلى ملف مليء بالحسابات والتعقيدات.
مثال شرط بسيط داخل Template
{% if books %}
<p>يوجد {{ books|length }} كتابًا.</p>
{% else %}
<p>لا توجد كتب بعد.</p>
{% endif %}
هذا مقبول. أما الحسابات الثقيلة، فمكانها ليس هنا.
كيف يساعد MVC/MVT على صيانة المشروع؟
الصيانة هي المكان الذي تظهر فيه قيمة المعمارية الحقيقية. في البداية قد تظن أن التقسيم مجرد "تنظيم جميل"، لكنه في الحقيقة أكثر من ذلك بكثير. عندما يطلب منك العميل تعديل طريقة العرض، فأنت لا تريد أن تلمس قاعدة البيانات. وعندما تحتاج إلى تغيير منطق التخزين، فأنت لا تريد أن تفتح ملفات HTML.
هذا الفصل يمنحك أشياء مهمة:
سهولة التعديل
سهولة الاختبار
سهولة إعادة الاستخدام
تقليل التداخل بين الأجزاء
وضوح أكبر للمطورين الجدد
الاختبار أسهل عندما يكون كل شيء في مكانه
من أكبر مزايا Django أنه يسهل كتابة اختبارات على كل طبقة تقريبًا. فإذا كانت الـ views قصيرة، والنماذج واضحة، والقوالب مخصصة للعرض، يصبح اختبار التطبيق أكثر سلاسة.
مثال اختبار Model
from django.test import TestCase
from .models import Book
from datetime import date
class BookModelTest(TestCase):
def test_string_representation(self):
book = Book.objects.create(
title='Clean Code',
author='Robert C. Martin',
published_at=date(2008, 8, 1),
description='A book about writing better code.'
)
self.assertEqual(str(book), 'Clean Code')
هذا النوع من الاختبارات يساعدك على التأكد من أن النموذج يعمل كما تتوقع، خاصة مع ازدياد حجم المشروع.
متى يختلط الأمر على المبتدئين؟
عادة يحدث ذلك في ثلاث حالات:
الأولى عندما يعتقد المبتدئ أن View في Django هي صفحة HTML.
الثانية عندما يضع كل المنطق داخل Template.
الثالثة عندما يكتب كودًا طويلًا جدًا داخل View دون تنظيم.
وهنا يبدأ المشروع في فقدان شكله المنظم. من المهم أن تتذكر دائمًا أن Django لا يريد منك أن تضع كل شيء في مكان واحد. يريد منك أن تفكر مثل مهندس يوزع العمل على طبقات، لا مثل شخص يكدّس الأسطر في ملف واحد.
علاقة Django بـ MTV أحيانًا بدل MVT
قد تقرأ أحيانًا أن Django يعتمد على MTV وليس MVT. هذا ليس خطأ كبيرًا بقدر ما هو اختلاف في طريقة التسمية. بعض المصادر تسميه MTV لأن Django داخليًا يفسر الأمور بطريقة مختلفة قليلًا، لكن في الممارسة العملية والشرح التعليمي الشائع ستسمع غالبًا MVT.
المهم هنا ليس الاسم بقدر ما هو الفهم:
هناك Model
وهناك View
وهناك Template
أما التفاصيل الدقيقة للتسمية، فهي غالبًا لا تغيّر طريقة كتابة التطبيق اليومي.
مثال أكثر واقعية: مدونة بسيطة
لنأخذ مثالًا أقرب للواقع: مدونة.
models.py
from django.db import models
class Category(models.Model):
name = models.CharField(max_length=100)
def __str__(self):
return self.name
class Post(models.Model):
title = models.CharField(max_length=200)
content = models.TextField()
category = models.ForeignKey(Category, on_delete=models.CASCADE)
created_at = models.DateTimeField(auto_now_add=True)
def __str__(self):
return self.title
views.py
from django.shortcuts import render
from .models import Post
def post_list(request):
posts = Post.objects.select_related('category').all().order_by('-created_at')
return render(request, 'blog/post_list.html', {'posts': posts})
post_list.html
<!DOCTYPE html>
<html lang="ar">
<head>
<meta charset="UTF-8">
<title>المدونة</title>
</head>
<body>
<h1>آخر المقالات</h1>
{% for post in posts %}
<article>
<h2>{{ post.title }}</h2>
<p>التصنيف: {{ post.category.name }}</p>
<p>{{ post.content|truncatewords:30 }}</p>
<small>{{ post.created_at }}</small>
</article>
<hr>
{% empty %}
<p>لا توجد مقالات حتى الآن.</p>
{% endfor %}
</body>
</html>
هذا المثال يوضح كيف يعمل Django بطريقة طبيعية جدًا: البيانات في Model، المنطق في View، والعرض في Template.
كيف تكتب كودًا منظمًا داخل Django؟
هناك عدة عادات مفيدة جدًا:
أولًا، لا تجعل الـ view مسؤولًا عن كل شيء.
ثانيًا، استخدم القوالب للعرض فقط.
ثالثًا، اجعل الـ model يحتوي على ما يخص البيانات وسلوكها.
رابعًا، عند الحاجة، قسم المنطق إلى ملفات مساعدة أو طبقات خدمة.
هذا الأسلوب لن يجعل الكود فقط "جميلًا"، بل سيجعل حياتك أسهل عندما يعود المشروع ليكبر من جديد.
متى أستخدم Class-Based Views؟
Django يدعم Function-Based Views وClass-Based Views.
إذا كنت في بداية الطريق، فغالبًا ستفهم الـ Function-Based Views أسرع. أما الـ Class-Based Views فتفيدك عندما تريد إعادة استخدام منطق مشترك أو بناء صفحات متشابهة بسرعة أكبر.
مثال Class-Based View
from django.views.generic import ListView
from .models import Book
class BookListView(ListView):
model = Book
template_name = 'books/list.html'
context_object_name = 'books'
هذا المثال يختصر الكثير من الكود، لكنه يحتاج فهمًا جيدًا حتى لا يتحول إلى سحر غامض. من الجميل أن تتعلمه بعد فهم الأساسيات، لا قبلها.
هل MVT أفضل من MVC؟
السؤال الأدق ليس "أفضل" بل "أنسب".
MVC وMVT كلاهما يعتمد على فصل المسؤوليات. الاختلاف في التوزيع الداخلي، وليس في الهدف النهائي. Django اختار MVT لأنه يناسب فلسفته وأسلوب عمله. وفي النهاية، ما يهمك كمطور هو أن تبني تطبيقًا واضحًا وقابلًا للصيانة.
إذا كنت تفهم MVC، فسوف تفهم MVT بسرعة.
وإذا فهمت MVT جيدًا، فسوف تصبح أفكار MVC أسهل أيضًا.
كيف تتذكر الفرق بسرعة؟
هناك طريقة بسيطة جدًا:
في MVC، الـ View هي الواجهة، والـ Controller هو المنظم.
في Django MVT، الـ Template هي الواجهة، والـ View هي المنظم.
هذه الجملة وحدها تختصر الكثير.
أخطاء شائعة يجب تجنبها
من الأخطاء التي يقع فيها كثيرون:
وضع SQL أو منطق بيانات معقد داخل الـ view.
كتابة HTML كبير جدًا داخل ملفات Python.
تنفيذ حسابات معقدة في template.
عدم استخدام
get_object_or_404.ترك الـ models بدون أساليب مفيدة تساعد على إعادة الاستخدام.
عدم تقسيم المشروع إلى تطبيقات apps عندما يكبر.
هذه الأخطاء لا تظهر دائمًا في اليوم الأول، لكنها تظهر بوضوح عندما يصبح المشروع أكبر، وعندها تبدأ المعاناة الحقيقية.
مثال على استخدام get_object_or_404
from django.shortcuts import render, get_object_or_404
from .models import Post
def post_detail(request, post_id):
post = get_object_or_404(Post, id=post_id)
return render(request, 'blog/post_detail.html', {'post': post})
هذا أفضل من جلب العنصر ثم التحقق يدويًا من وجوده في كل مرة.
قيمة الفصل بين المنطق والعرض في الحياة اليومية
عندما تعمل على موقع حقيقي، قد يتغير التصميم كثيرًا، بينما تبقى البيانات نفسها. أو قد تتغير قواعد العمل بينما يبقى شكل الصفحة كما هو. هنا تظهر روعة الفصل بين الطبقات. لأنك تستطيع تغيير قالب العرض دون أن تلمس منطق البيانات، أو تعديل الـ model دون أن تعيد بناء كل الواجهات.
وهذا ليس رفاهية تقنية فقط، بل توفير حقيقي للوقت والجهد. وأحيانًا، عندما تتذكر كم من الساعات قد تضيع بسبب مشروع غير منظم، ستعرف لماذا يحب المطورون هذا النوع من البنى.
هل أحتاج أن أحفظ التعاريف أم أفهم التدفق؟
الأفضل دائمًا هو الفهم أولًا.
يمكنك حفظ أن:
Model = البيانات
View = المنطق
Template = العرض
لكن الأهم هو أن تفهم القصة الكاملة: كيف يدخل الطلب، أين يذهب، من يعالجه، ومن يعرض النتيجة. إذا فهمت هذه الرحلة، فلن تنسى البنية بسهولة، حتى لو نسيت بعض المصطلحات أحيانًا.
خلاصة عملية جدًا
يمكن تلخيص الفكرة كلها في هذا المشهد:
المستخدم يطلب صفحة.
Django يوجه الطلب إلى view مناسبة.
الـ view تتحدث مع model إذا احتاجت بيانات.
ثم ترسل هذه البيانات إلى template.
والـ template تنتج الصفحة النهائية التي يراها المستخدم.
هذا هو قلب Django، وهذا هو السبب الذي يجعل بنية MVT مناسبة جدًا لتطوير مشاريع نظيفة ومنظمة.
كلمة أخيرة من مطوّر إلى مطوّر
أجمل ما في Django أنه لا يطلب منك أن تكون عبقريًا من أول يوم، بل يطلب منك فقط أن تتعلم كيف تفكر بطريقة مرتبة. وحين تبدأ تلاحظ كيف تتوزع المسؤوليات بين Model وView وTemplate، ستشعر أن الكود أصبح أقل فوضى، وأكثر احترامًا لعقلك ووقتك. وربما، بعد بعض المشاريع، ستصل إلى تلك اللحظة التي تنظر فيها إلى مشروع قديم لك وتقول: "الحمد لله أنني تعلّمت الفصل بين الأجزاء قبل أن يتضخم كل شيء."
إذا كنت تبني مشروعًا حقيقيًا اليوم، فاذكر هذه القاعدة البسيطة:
دع كل جزء يقوم بعمله فقط، ولا تطلب من template أن يفكر بدل view، ولا من view أن تكون قاعدة بيانات، ولا من model أن يتحول إلى صفحة HTML.