خرید هاست | خرید هاست و دامین | خرید سرور مجازی واختصاصی-پارس وب سرور

چه وقت از Django استفاده کنیم؟ و چرا ؟

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

باید ابتدا محاسبه کنید که چه زبانی برای رسیدن به هدف مورن نظرتان بهتر است. چه چیزهایی اهمیت بیشتری دارد، امنیت؟ توسعه سریع؟ مقیاس‌پذیری؟ تطبیق پذیری؟ پشتیبانی؟

کارشناسان بعد از سال‌ها تجربه با تکنولوژی‌های مختلف (چه سمت وب و چه سمت موبایل)، به این معتقد هستند که Django قابلیت‌های کاملی را ارائه می‌کند که سایر فریم‌ورک‌ها از آنها بی بهره هستند.

وبسایت‌های محبوب زیادی از Django استفاده می کنند ، Instagram و Pinterest و یا حتی Facebook از Django برای قابلیت های متفاوتشان از این زبان بهره می گیرند . Django برای انتشار و یا publishing استفاده می‌شود، پس این جای تعجب نیست که سایت‌هایی نظیر Washington Post و Smithsonian Magazine از Django استفاده می‌کنند.

 

چه وقت از Django استفاده کنیم؟

 

اگر چند مورد زیر را بررسی کنید (بدون مخالفت شدید با هرکدام از آن‌ها)، به احتمالا Django برای پروژه شما مناسب است.

البته مهارت‌های شما و یا تیم‌تان روی پروژه باید درنظر گرفته شود.

اگر میدانید وب چطور کار میکند ، استفاده از Django بدون مشکل خواهد بود. تنها به این نیاز خواهید داشت که بدانید ساختار Django (و مطمئنا به همراه چند مورد دیگر) چگونه است،و بعد پروژه را جلو ببرید.

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

چه زمانی از Django استفاده کنیم؟

 

ساخته شدن فریم‌ورک Django با پایتون

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

Django فریم‌ورکی با ویژگی Batteries Included است

Batteries Included به این معنی است که Django اکثر کتابخانه‌ها و ابزارهایی که برای استفاده‌های مرسوم نیاز است را به همراه خود دارد. Django ORM، Middlewares، Authentication، HTTP libraries، Multi-site supprort، i18n، Django Admin، template engine و … (که به اصطلاح باتری‌ها (batteris) هستند) هیچ کدام از فریم‌ورک‌های دیگری که می‌شناسم، این حجم از قابلیت‌ها را یکجا ندارند.

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

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

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

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

چرخ را دوباره اختراع نکنید، این را بیاد دارید؟ وقت خود را بر روی موارد مهم صرف کنید و اجازه دهید که Django مابقی قضیه را برایتان انجام دهد.

Django Admin

گرچه که من در بخش قبلی اشاره کردم، این بخش به توجه بیشتری نیاز دارد. فریم‌ورک‌های زیادی نظیر Laravel، Yii و … تلاش کرده‌اند که کار با پنل Admin را ساده‌تر کنند. پروژه‌های بسیاری را توسط فریم‌ورک‌های مختلف توسعه داده‌ام، هیچ کدام از آن‌ها ذره‌ای به Django در ساده و روان‌بودن کارکردن با پنل Admin نزدیک نیستند.

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

Django Admin به خوبی ساختار یافته است. در برخی از پروژه‌هایم از خود Django admin استفاده کردم و در برخی دیگر به طور کامل آن را با templateهایی که از پایه شخصی‌سازی کرده بودم جایگزین کردم. در هر موردی، اگر چنین کاری را در سایر فریم‌ورک‌هایی که میشناسم، انجام می‌دادم، زمان بیشتری می‌گرفت.

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

قاعده DRY و یا Don’t Repeat Yourself

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

در Laravel، برای مثال نیاز دارید تا اعتبارسنجی هر route را به صورت جداگانه بنویسید. این مورد در اکثر فریم‌ورک‌ها وجود دارد. برای اینکه کدتان با قاعده DRY سازگار باشد، باید تلاش کنید تا این قاعده را پیاده کنید. مخصوصا هنگامی که در یک تیم هستید بررسی و چک کردن، سخت‌تر می‌شود.

در طرف دیگر، فریم‌ورک Django، به گونه‌ای طراحی شده است که برای نقض قاعده DRY، باید از مسیر خودتان در پروژه خارج شوید. همانگونه که باید باشد است، درست است؟ آیا به مثال نیاز دارید؟

در اینجا نحوه کار اعتبار سنجی و migrationهای دیتابیس‌ها را در Django بررسی می‌کنیم:

  1. مدلی به همراه فیلدهای مورد نیاز ایجاد کنید. همچنین اعتبارسنجی‌ها و محدودیت‌‌ها بیشتری که نیاز است را هم مشخص کنید.
  2. migrationها توسط یک دستور در خط فرمان ایجاد می‌شوند: python manage.py makemigrations
  3. تغییرات در دیتابیس توسط این دستور در خط فرمان اعمال خواهند شد: python manage.py migrate
  4. اعتبارسنجی‌ها و محدودیت‌ها به صورت خودکار توسط هر کدام از عملیات‌های CRUD (یعنی Create, Read, Update, Delete) بررسی می‌شوند (چه در Django Admin و چه در Django Rest). در واقع نیازی ندارید تا دوباره اعتبارسنجی‌ها را خودتان بنویسید.
  5. از مدل مشابه‌ای برای ایجاد CRUD برای ظاهر بخش Django Admin استفاده می‌شود و به HTML/CSS شخصی‌سازی‌شده نیاز ندارد.

اگر این موارد را با سایر فریم‌ورک‌ها مقایسه کنید، فکر نمی‌کنم بتوانند تمام این کارها را تنها مثل چند خط زیر توسط Django انجام دهند:

class Employee(models.Model):
    name = models.CharField(max_length=127)
    email = models.EmailField(null=True, blank=True)
    created_at = models.DateTimeField(blank=True, null=True, auto_now_add=True)
    updated_at = models.DateTimeField(blank=True, null=True, auto_now=True)

این تنها در رابطه با “تکرار نکردن خودتان” (not repeating yourself) نیست. این قضیه به شما کمک می‌کند تا از ایجاد مشکلات و باگ‌ها در آینده پروژه پیشگیری کنید. همه ما در این وضعیت قرار داشتیم که وقتی یک چیزی را در جایی از کد تغییر می‌دهیم و فراموش می‌کنیم که مابقی مواردی که نیاز به تغییر دارند را، تغییر دهیم و متوجه این مشکل نخواهیم شد، تا اینکه به طور مثال مشتری و یا کاربر این باگ را گزارش کند.

در Django، با توجه به تکه کد بالا، اگر بخواهید max_length یک فیلد را تغییر دهید، این تغییر را تنها در همینجا انجام دهید، به صورت خودکار این تغییر و سایر تغییرات شما بر روی اعتبارسنجی تمامی routeها و دیتابیس اعمال خواهد شد.

Django Framework ORM

Django قابلیت ORM و یا Object-Relational Mapping را به طور کامل فراهم می‌کند. با ORMهای زیادی در تکنولوژی‌های مختلف کار کرده‌ام، از جمله Eloquent، greenDAO، Yii AR و … تمامی آن‌ها از queryهای پایه‌ای به طور کامل پشتیبانی می‌کنند اما گاهی اوقات مجبور بودم که خودم queryهای خام را برای دیتابیس بنویسم، زیرا این ORM در این مورد، نتوانسته نیازم را برطرف کند.

تا به حال، هنگام استفاده از Django ORM به این مشکلات برنخورده‌ام، زیرا به گونه‌ای ساخته شده است که به کل فراموش می‌کنید که در حال کار با queryهای دیتابیس هستید. یک ORM باید اینگونه باشد. در زیر چند مثال از Django ORM مشاهده می‌کنیم:

به طور مثال برای دریافت ۵ رکورد آخر از مدل Employee که در آن‌ها rank برابر ۱۰ و سن کمتر و مساوی از ۳۰ است از خط زیر استفاده می‌کنیم:

top_young_employees = Employee.objects.filter(rank=10, age__lte=30)[:5]

و یا برای وارد کردن یک رکورد با مقادیر مشخص:

employee = Employee.objects.create(name=’John Doe’, age=35, country=’IN’)

و در نهایت برای مشاهده مقدار یک فیلد:

print(employee.name)


توسعه سریع

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

با استفاده از Django، می‌توانید کارهایتان را با سرعت وصف‌ناپذیری انجام دهید. به هنگام استفاده از Django، خواهید دید که با چه سرعتی می‌توانیم UI پنل admin، جداول دیتابیس و اعتبارسنجی‌های بالا را ایجاد کنیم.

این تنها بخش کوچکی از یک کوه یخ بود.

گرچه این ویژگی به خودی خود قابلیت حساب نمی‌شود. درحقیقت ویژگی‌ایی است که همراه قاعده DRY، مدل ORM، موتور template و فلسفه “batteries included” ارائه می‌شود.

 

امنیت فریم‌ورک Django

بیایید روراست باشیم، توسعه‌دهندگان گاهی اوقات تنبل هستند. حداقل من اینطور هستم. بیشتر اوقات انجام برخی taskها را که اهمیت زیادی ندارند را به تعویق می‌اندازم. عدم انجام این taskها معمولا باعث ایجاد آسیب‌پذیری‌ها و مشکلات امنیتی می‌شود.

دلیلی که بیشتر باعث می‌شود Django را دوست داشته باشم این است که برای ارائه قابلیت توسعه سریع، امنیت را به خطر نمی‌اندازد. قابلیت‌های امنیتی به صورت پیشفرض فعال شده‌اند و این که شما تنبل باشید یا نه اهمیتی ندارد.

متن‌باز، به طور کامل مستندسازی شده، جامعه‌کاربری بزرگ و …

به دلیل متن‌باز و معروف بودن، Django جامعه کاربری بزرگ و مفیدی دارد. فرض می‌کنم که از مزایای متن‌باز بودن یک پروژه آگاهی دارید. Django هم دارای این مزایاست.

مستندات رسمی Django برای توسعه‌دهندگان بیش‌از حد نیاز آن‌ها است. اگر در جایی گیر کنید و یا با مشکلی روبرو شوید، به راحتی می‌توانید راه‌حل مشکلات خود را پیدا کنید. علاوه‌براین Stack Overflow، پر از سوال و جواب‌هایی است که به Django مربوط است.

تا جایی که دیده‌ایم Django کتابخانه‌های زیادی را مخصوص خودش ایجاد کرده است، شاید باعث حیرتتان شود که هیچ کتابخانه‌ای را برای تست نساخته است. به این معنا نیست که Django از تست‌گرفتن پشتیبانی نمی‌کند، مطمئنا پشتیبانی می‌کند. در مستندات Django یک بخش کاملا جدا مخصوص تست‌گرفتن پروژه است. با توجه به قانون “چرخ را دوباره اختراع نکنید”، وقتی پایتون کتابخانه‌ای عالی مخصوص تست‌گرفتن دارد، ایجاد کتابخانه‌ای مخصوص این کار توسط Django کار بیهوده‌ای است. Django به خوبی از این قضیه پشتیبانی می‌کند. همچنین با کتابخانه‌های دیگری نظیر pytest نیز به خوبی کار می‌کند.

 

5/5 - (2 امتیاز)
خروج از نسخه موبایل