اول یک سوءتفاهم را کنار بگذاریم؛ Django زبان برنامه نویسی نیست

گاهی می‌شنویم کسی می‌گوید «زبان Django»، اما Django خودش زبان نیست. زبانی که با آن کد می‌نویسید Python است؛ جنگو مجموعه‌ای از ابزارها و قراردادهاست که توسعه وب با Python را منظم‌تر می‌کند.

پس یادگیری Django یعنی یاد گرفتن اینکه چطور با Python یک برنامه وب بسازید که Request را بگیرد، با دیتابیس کار کند، کاربر و فرم را مدیریت کند و در نهایت پاسخ مناسبی به مرورگر برگرداند.

Django چیست و چه مشکلی را برای برنامه نویس حل می‌کند؟

فرض کنید می‌خواهید یک سایت واقعی بسازید. خیلی زود می‌بینید بعضی کارها تقریباً در هر پروژه‌ای تکرار می‌شوند: کاربر، دیتابیس، فرم، URL، سطح دسترسی و پردازش درخواست‌ها. نوشتن همه این بخش‌ها از صفر برای هر پروژه هم زمان‌بر است و هم مستعد خطا.

Django بخش زیادی از این زیرساخت تکراری را از قبل آماده کرده و برایش یک ساختار مشخص دارد. نتیجه این است که به‌جای درگیر شدن دوباره با همان مسائل پایه، می‌توانید وقت بیشتری برای منطق مخصوص پروژه بگذارید.

البته این به معنی «ساخت خودکار پروژه» نیست. هنوز باید مدل داده، منطق کسب‌وکار و رفتار سیستم را خودتان طراحی کنید. جنگو فقط کاری می‌کند هر بار برای نیازهای تکراری از نقطه صفر شروع نکنید.

Django در بک‌اند کجای ماجرا قرار می‌گیرد؟

یک فروشگاه اینترنتی را در نظر بگیرید. شما روی یک محصول کلیک می‌کنید و چند لحظه بعد اطلاعاتش روی صفحه می‌آید. پشت همین اتفاق ساده، سرور باید بفهمد کدام محصول خواسته شده، اطلاعات را از کجا بخواند و چه چیزی به مرورگر برگرداند.

حالا سبد خرید، ورود کاربر، آدرس و ثبت سفارش را هم اضافه کنید. بیشتر منطق این اتفاق‌ها در بک‌اند اجرا می‌شود؛ جایی که داده و قوانین سیستم کنار هم قرار می‌گیرند.

نقش Django این است که برای این بخش‌های مختلف یک چهارچوب بدهد تا منطق پروژه بین فایل‌ها و قسمت‌های پراکنده گم نشود و بتوانید آن را قابل فهم‌تر توسعه دهید.

MVT آن‌قدرها هم پیچیده نیست؛ فقط مسئولیت‌ها را جدا می‌کند

ایده MVT ساده است: هر بخش یک مسئولیت مشخص داشته باشد. Model با داده سروکار دارد، View منطق درخواست را مدیریت می‌کند و Template چیزی را که باید کاربر ببیند نمایش می‌دهد.

Project و App؛ پروژه را به بخش‌های قابل مدیریت تقسیم کنیم

در Django معمولاً یک Project اصلی دارید که تنظیمات کلی آنجاست. قابلیت‌های مختلف را هم می‌توانید در Appهای جدا نگه دارید تا هر بخش مسئول کار مشخصی باشد.

مثلاً در یک فروشگاه اینترنتی، کاربران، محصولات و سفارش‌ها می‌توانند هرکدام App جداگانه‌ای داشته باشند. این کار باعث می‌شود تغییر یک بخش کمتر روی بقیه قسمت‌ها سایه بیندازد.

هرچه پروژه بزرگ‌تر شود، ارزش این جداسازی بیشتر معلوم می‌شود؛ پیدا کردن کد، تغییر دادن آن و اضافه کردن قابلیت تازه خیلی راحت‌تر خواهد بود.

URL Routing؛ هر آدرس باید مقصد مشخصی داشته باشد

وقتی کاربر یک آدرس را باز می‌کند، Django باید بداند این درخواست باید به کدام View برسد. URL Routing همان نقشه‌ای است که این مسیر را مشخص می‌کند.

مثلاً /products/ می‌تواند لیست محصولات را نمایش دهد و مسیر دیگری شناسه یک محصول را بگیرد و صفحه جزئیات همان محصول را باز کند.

URL مرتب فقط ظاهر خوبی ندارد؛ وقتی بعداً سراغ کد برمی‌گردید، راحت‌تر می‌فهمید هر درخواست از کجا وارد پروژه می‌شود.

View؛ جایی که تصمیم می‌گیریم با درخواست چه کار کنیم

وقتی URL مقصد را مشخص کرد، View تصمیم می‌گیرد چه اتفاقی بیفتد. ممکن است از دیتابیس چیزی بخواند، وضعیت کاربر را بررسی کند یا بخشی از منطق برنامه را اجرا کند.

بعد از این مرحله، View می‌تواند داده را به Template بدهد، Redirect کند یا نوع دیگری از Response برگرداند.

Django هم Function-Based View دارد و هم Class-Based View. اوایل مسیر لازم نیست درگیر انتخاب بین این دو شوید؛ مهم‌تر این است که بفهمید View چه مسئولیتی دارد و چه زمانی باید چه کاری انجام دهد.

Template؛ داده‌ای که در بک‌اند آماده شده باید جایی دیده شود

Template فقط یک HTML ثابت نیست. View می‌تواند داده را به آن بدهد و صفحه بر اساس همان اطلاعات ساخته شود؛ مثلاً نام کاربر، لیست محصولات یا نتیجه یک جست‌وجو.

برای نمونه، View محصولات را از دیتابیس می‌گیرد و Template آن‌ها را به شکل کارت، جدول یا هر چیدمان دیگری به کاربر نشان می‌دهد.

با Template Inheritance هم لازم نیست Header، Footer و ساختارهای مشترک را در هر صفحه دوباره بنویسید؛ یک بار تعریف می‌کنید و بقیه صفحات از همان استفاده می‌کنند.

Model و ORM؛ جایی که داده‌های واقعی پروژه وارد بازی می‌شوند

تقریباً هیچ پروژه واقعی بدون داده نیست؛ کاربر، مقاله، محصول، سفارش یا پیام باید جایی ذخیره شوند. در Django شکل این اطلاعات را معمولاً با Model تعریف می‌کنید.

مثلاً Product می‌تواند نام، قیمت، موجودی و تاریخ ایجاد داشته باشد. بعد ORM کاری می‌کند برای بسیاری از کارهای روزمره دیتابیس بتوانید با خود Python کار کنید.

ساختن رکورد، جست‌وجو، فیلتر، ویرایش، حذف و کار با رابطه بین داده‌ها بخش بزرگی از کار روزمره با ORM است.

داده‌ها به هم وصل‌اند؛ رابطه‌ها را از اول درست طراحی کنید

در پروژه واقعی جدول‌ها جزیره‌های جدا نیستند. مقاله نویسنده دارد، سفارش به کاربر وصل است و یک محصول می‌تواند در چند دسته قرار بگیرد.

Django برای همین ارتباط‌ها ابزارهایی مثل ForeignKey، OneToOneField و ManyToManyField در اختیار شما می‌گذارد.

اگر رابطه‌ها را از ابتدا درست طراحی کنید، بعداً هنگام گزارش‌گیری، توسعه قابلیت‌ها و تغییر ساختار داده دردسر خیلی کمتری خواهید داشت.

Migration؛ تغییر Model باید به دیتابیس هم برسد

فرض کنید چند هفته بعد تصمیم می‌گیرید به محصول فیلد تخفیف اضافه کنید. تغییر Model به‌تنهایی کافی نیست؛ دیتابیس هم باید بداند ساختارش تغییر کرده است.

Migration این تغییرات را ثبت و اعمال می‌کند تا ساختار دیتابیس قدم‌به‌قدم همراه Modelهای پروژه جلو برود.

در کار تیمی این موضوع مهم‌تر هم می‌شود، چون همه اعضا باید بتوانند همان تغییرات دیتابیس را روی محیط خودشان اعمال کنند.

Form و Validation؛ به ورودی کاربر بدون بررسی اعتماد نکنید

کاربر ممکن است فیلدی را خالی بگذارد، ایمیل اشتباه وارد کند یا مقداری بفرستد که اصلاً انتظارش را ندارید. قبل از استفاده از این داده‌ها باید آن‌ها را بررسی کنید.

Form و ModelForm در Django کمک می‌کنند هم ساخت فرم‌ها و هم بررسی داده‌های ورودی ساختار مشخص‌تری داشته باشد.

Validation فقط برای نشان دادن پیام خطا به کاربر نیست؛ جلوی ورود داده خراب یا نامعتبر به بخش‌های بعدی سیستم را هم می‌گیرد.

Authentication و Permission؛ فقط ورود مهم نیست، دسترسی هم مهم است

در خیلی از پروژه‌ها ثبت‌نام و ورود جزو اولین نیازهاست. Django برای مدیریت کاربر، رمز عبور، Login و Logout ابزارهای داخلی دارد و لازم نیست همه این بخش‌ها را از صفر بسازید.

اما اینکه کاربر وارد شده باشد کافی نیست. باید مشخص باشد چه چیزهایی را می‌تواند ببیند یا تغییر دهد.

Permission و Group برای همین کار هستند؛ مثلاً مدیر، کارمند و کاربر عادی می‌توانند سطح دسترسی متفاوتی داشته باشند.

Middleware؛ لایه‌ای که می‌تواند قبل و بعد از View وارد عمل شود

Middleware را می‌توان مثل یک لایه در مسیر Request و Response دید؛ قبل از اینکه درخواست به View برسد یا بعد از آماده شدن پاسخ می‌تواند کاری انجام دهد.

بخشی از Session، Authentication و امکانات امنیتی خود Django هم از همین سازوکار استفاده می‌کنند.

وقتی پروژه پیچیده‌تر شود، می‌توانید Middleware اختصاصی خودتان را هم برای نیازهای مشخص سیستم بنویسید.

Static و Media؛ دو دسته فایل که بهتر است از همان اول جدا بمانند

CSS، JavaScript و تصویرهایی که جزو خود رابط سایت هستند معمولاً در گروه Static Files قرار می‌گیرند.

در مقابل، فایل‌هایی که کاربر یا مدیر آپلود می‌کند—مثلاً عکس پروفایل یا تصویر محصول—معمولاً Media Files هستند.

اگر از همان ابتدا این دو را درست جدا کنید، تنظیمات فایل‌ها و Deploy در ادامه خیلی تمیزتر پیش می‌رود.

امنیت در Django خیلی فراتر از گذاشتن رمز روی Admin است

ورودی کاربر باید بررسی شود، دسترسی‌ها باید دقیق باشند و اطلاعات حساس نباید بی‌دلیل در دسترس بخش‌های مختلف قرار بگیرند.

Django برای تعدادی از خطرهای رایج وب محافظت‌های داخلی دارد، اما این امکانات جای فهم امنیت را نمی‌گیرند. باید بدانید هرکدام چه کاری می‌کنند و کجا هنوز مسئولیت با خود شماست.

CSRF، Session، Password Hashing و Permission از همان موضوعاتی هستند که اگر قرار است Django را جدی استفاده کنید، نمی‌شود از کنارشان سریع رد شد.

Testing؛ چون همیشه چیزی که می‌شکند همان بخشی نیست که تغییرش داده‌اید

گاهی یک تغییر کوچک در Model یا View بخشی دیگر را خراب می‌کند و حتی همان لحظه متوجهش نمی‌شوید. تست‌های خودکار دقیقاً برای چنین موقعیت‌هایی ارزش پیدا می‌کنند.

با تست می‌توانید رفتار Model، View، Form و منطق اصلی پروژه را بررسی کنید و قبل از رسیدن مشکل به کاربر متوجه آن شوید.

بهتر است تست را بخشی از روند توسعه ببینید، نه کاری که فقط در پایان پروژه و وقتی همه چیز به‌هم ریخته سراغش می‌رویم.

با Django چه چیزهایی می‌شود ساخت؟

مسیر یادگیری Django؛ از مفاهیم پایه تا یک پروژه واقعی

قرار نیست این فهرست را با عجله تیک بزنید. بهتر است هر بخش را روی یک پروژه کوچک امتحان کنید و وقتی کاربردش را فهمیدید سراغ مرحله بعد بروید.

اشتباه رایج این است که Django را فصل‌به‌فصل حفظ کنیم

اگر Model، URL، View و Template را فقط به‌عنوان چند فصل جدا بخوانید، موقع شروع پروژه احتمالاً سؤال اصلی‌تان این می‌شود که «حالا این‌ها را چطور به هم وصل کنم؟»

راه بهتر این است که از همان ابتدا یک پروژه کوچک کنار دستتان باشد. Model که می‌خوانید یک داده واقعی بسازید؛ Form که یاد می‌گیرید همان داده را از کاربر بگیرید؛ Authentication که رسید، ورود کاربر را به همان پروژه اضافه کنید.

به این شکل، Django کم‌کم از یک فهرست اصطلاحات تبدیل می‌شود به سیستمی که منطقش را می‌فهمید و می‌توانید با آن کار کنید.

سوالات متداول درباره آموزش Django