در این فصل در مورد موضوعات زیر صحبت خواهیم کرد:
- چرا جنگو؟
- داستان جنگو
- جنگو چگونه کار می کند؟
- الگو چیست؟
- مجموعه های الگوهای شناخته شده
- الگوها در جنگو
بر اساس گزارش جهانی استارتاپ بووی گای، در سال 2013 بیش از 136000 شرکت اینترنتی در سراسر جهان وجود داشت که بیش از 60000 شرکت فقط در آمریکا وجود داشت. از این تعداد، 87 شرکت آمریکایی بیش از یک میلیارد دلار ارزش دارند. مطالعه دیگری می گوید که از 12000 نفر بین 18 تا 30 سال در 27 کشور، بیش از دو سوم فرصت هایی را برای کارآفرین شدن می بینند.
این رونق کارآفرینی در استارت آپ های دیجیتال در درجه اول به دلیل ارزان شدن و فراگیر شدن ابزارها و فناوری های استارت آپ ها است. ایجاد یک برنامه وب کامل به لطف فریمورک های قدرتمند، زمان و مهارت بسیار کمتری نسبت به گذشته می طلبد.
فیزیکدانان، مربیان، هنرمندان و بسیاری دیگر بدون پیشینه مهندسی نرم افزار در حال ایجاد برنامه های کاربردی مفیدی هستند که به طور قابل توجهی در حال پیشرفت حوزه خود هستند. با این حال، آنها ممکن است از اصول طراحی مهندسی نرم افزار مورد نیاز برای ساخت نرم افزار بزرگ و قابل نگهداری آگاه نباشند.
مطالعه چهار پیادهسازی مختلف از یک برنامه کاربردی مبتنی بر وب در نروژ نشان داد که پیادهسازیهایی با بوهای کد شناخته شده و طرحهای ضد الگو مستقیماً با مشکلات نگهداری مرتبط هستند. نرم افزاری که طراحی ضعیفی دارد ممکن است به همان اندازه کار کند، اما انطباق با الزامات در حال تحول در دنیایی که به سرعت در حال تغییر است، دشوار است.
مبتدی ها اغلب مشکلات طراحی را در اواخر پروژه خود کشف می کنند. به زودی، آنها سعی می کنند همان مشکلاتی را که دیگران با آن مواجه شده اند، حل کنند. اینجاست که درک الگوها واقعاً می تواند به صرفه جویی در وقت آنها کمک کند.
هر برنامه وب متفاوت است، مانند یک تکه مبلمان دست ساز. به ندرت یک مبل تولید انبوه پیدا می کنید که تمام نیازهای شما را به خوبی برآورده کند. حتی اگر با یک نیاز اساسی مانند وبلاگ یا شبکه اجتماعی شروع کنید، نیازهای شما به آرامی افزایش مییابد و به راحتی میتوانید با بسیاری از محلولهای نیمهپخت که با چسب نواری روی محلولهای کاتر کوکیها چسبانده شدهاند، خاتمه دهید.
به همین دلیل است که FrameWork های وب مانند جنگو یا ریل بسیار محبوب شده اند. FrameWorkها توسعه را سرعت میبخشند و بهترین روشها را در خود دارند. با این حال، آنها همچنین به اندازه کافی انعطافپذیر هستند تا به شما امکان دسترسی به لولهکشی کافی برای کار را بدهند. امروزه فریم ورک های وب در همه جا وجود دارند و اکثر زبان های برنامه نویسی حداقل یک فریم ورک انتها به انتها مشابه جنگو دارند.
احتمالا پایتون نسبت به بسیاری از زبان های برنامه نویسی FrameWork های وب بیشتری دارد. نگاهی گذرا به فهرست بسته پایتون (PyPI) 13045 بسته شگفتانگیز مربوط به محیطهای وب را نشان میدهد. برای جنگو، مجموع 9091 بسته است. ویکی پایتون بیش از 54 FrameWork وب فعال را فهرست میکند که محبوبترین آنها جنگو، فلاسک، پیرامید و زوپ است. پایتون همچنین دارای تنوع گسترده ای در فریمورک ها است. فریم ورک میکرو وب بطری فشرده تنها یک فایل پایتون است که هیچ وابستگی ندارد و به طرز شگفت انگیزی قادر به ایجاد یک برنامه وب ساده است.
علیرغم این گزینههای فراوان، جنگو با اختلاف زیادی به عنوان یک مورد علاقه بزرگ ظاهر شده است. Djangosites.org بیش از 5263 سایت نوشته شده در جنگو را فهرست می کند، از جمله داستان های موفقیت معروفی مانند اینستاگرام، پینترست، و Disqus. همانطور که توضیحات رسمی می گوید، جنگو (https://djangoproject.com) یک FrameWork وب سطح بالا پایتون است که توسعه سریع و طراحی تمیز و عملی را تشویق می کند. به عبارت دیگر، این یک FrameWork وب کامل با باتری هایی است که دقیقاً مانند پایتون در آن گنجانده شده است. رابط مدیریت خارج از جعبه، یکی از ویژگی های منحصر به فرد جنگو، برای ورود و مدیریت اولیه داده ها بسیار مفید است. مستندات جنگو به دلیل اینکه برای یک پروژه منبع باز بسیار خوب نوشته شده است مورد تحسین قرار گرفته است. در نهایت، جنگو در چندین وب سایت پر ترافیک آزمایش شده است. تمرکز فوقالعاده دقیقی بر امنیت با محافظت در برابر حملات رایج مانند اسکریپتهای متقاطع (XSS)، جعل درخواستهای متقابل سایت (CSRF) تا تهدیدات امنیتی در حال تکامل مانند الگوریتمهای هش رمز عبور ضعیف است
اگرچه میتوانید از جنگو برای ساخت هر نوع برنامه وب در تئوری استفاده کنید، اما ممکن است برای هر موردی بهترین نباشد. به عنوان مثال، برای نمونه سازی اولیه یک وب سرویس ساده در یک سیستم تعبیه شده با محدودیت های حافظه فشرده، ممکن است بخواهید از Flask استفاده کنید، در حالی که ممکن است در نهایت به دلیل استحکام و ویژگی های آن به جنگو بروید. ابزار مناسب برای کار را انتخاب کنید.
اگر به سایر FrameWork های وب عادت داشته باشید، برخی از ویژگی های داخلی، مانند رابط مدیر، ممکن است عجیب به نظر برسد. برای درک طراحی جنگو، بیایید دریابیم که چگونه به وجود آمد.
وقتی به اهرام مصر نگاه می کنید، فکر می کنید که چنین طراحی ساده و مینیمال باید کاملاً آشکار باشد. در حقیقت، آنها محصول 4000 سال تکامل معماری هستند. اهرام پله ای، طرح اولیه (و درهم و برهم)، دارای شش بلوک مستطیل شکل در حال کاهش بود. چندین بار اصلاحات معماری و مهندسی طول کشید تا اینکه سازههای آهکی مدرن، لعابدار و بادوام اختراع شدند.
با نگاه کردن به جنگو، ممکن است احساس مشابهی داشته باشید - آنقدر زیبا ساخته شده است که باید بی عیب و نقص تصور شده باشد. برعکس، نتیجه بازنویسیها و تکرارهای سریع در یکی از پرفشارترین محیطهای قابل تصور بود - اتاق خبر!
در پاییز 2003، دو برنامه نویس، آدریان هولواتی و سایمون ویلیسون که در روزنامه لارنس ژورنال-ورلد کار می کردند، مشغول ایجاد چندین وب سایت خبری محلی در کانزاس بودند. این سایتها، از جمله LJWorld.com، Lawrence.com، و KUsports.com، مانند بسیاری از سایتهای خبری، نه تنها درگاههای محتوا محور مملو از متن، عکس و ویدئو بودند، بلکه دائماً سعی میکردند نیازهای مردم را برآورده کنند. جامعه محلی لارنس با برنامههایی مانند فهرست راهنمای کسبوکار محلی، تقویم رویدادها و آگهیها.
البته این به معنای کار زیاد برای سایمون، آدریان و بعدها جاکوب کاپلان ماس بود که به تیم آنها پیوسته بودند. با مهلت های بسیار کوتاه، گاهی اوقات تنها با چند ساعت اطلاع رسانی. از آنجایی که اولین روزهای توسعه وب در پایتون بود، آنها مجبور بودند برنامه های وب را عمدتاً از ابتدا بنویسند. بنابراین، برای صرفه جویی در زمان گرانبها، آنها به تدریج ماژول ها و ابزارهای رایج را به چیزی به نام CMS تغییر دادند.
در نهایت، بخشهای مدیریت محتوا به پروژهای جداگانه به نام Ellington CMS تبدیل شد که به یک محصول تجاری موفق CMS تبدیل شد. بقیه CMS یک FrameWork زیربنایی منظم بود که به اندازه کافی عمومی بود که برای ساخت برنامه های کاربردی وب از هر نوع استفاده شود.
تا جولای 2005، این FrameWork توسعه وب به عنوان جنگو (تلفظ Jang-Oh) تحت مجوز منبع باز توزیع نرم افزار برکلی (BSD) منتشر شد. این نام از گیتاریست افسانه ای جاز جنگو راینهارت گرفته شد. و بقیه، همانطور که می گویند، تاریخ است.
جنگو به دلیل خاستگاه فروتنانهاش به عنوان یک ابزار داخلی، دارای موارد عجیب و غریب مخصوص لارنس ژورنال جهان بود. برای اینکه جنگو واقعاً هدف کلی باشد، تلاشی با عنوان حذف لارنس قبلاً در حال انجام بود.
با این حال، مهم ترین تلاش برای بازسازی که توسعه دهندگان جنگو باید انجام می دادند Removing the Magic نام داشت. این پروژه بلندپروازانه شامل پاکسازی تمام زگیلهایی بود که جنگو در طول سالها جمعآوری کرده بود، از جمله جادوی زیادی (یک اصطلاح غیررسمی برای ویژگیهای ضمنی) و جایگزینی آنها با کد پایتونیک طبیعیتر و صریحتر. برای مثال، کلاسهای مدل به جای اینکه مستقیماً از ماژول models.py
که در آن تعریف شده بودند وارد شوند، از یک ماژول جادویی به نام django.models.*
وارد میشدند.
در آن زمان، جنگو حدود صد هزار خط کد داشت و بازنویسی قابل توجهی از API بود. در 1 می 2006، این تغییرات، تقریباً به اندازه یک کتاب کوچک، در تنه نسخه توسعهدهنده جنگو ادغام شدند و با نسخه 0.95 جنگو منتشر شدند. این یک گام مهم به سوی نقطه عطف جنگو 1.0 بود.
هر ساله کنفرانس هایی به نام DjangoCons در سرتاسر جهان برای توسعه دهندگان جنگو برگزار می شود تا بتوانند با یکدیگر ملاقات کنند و با یکدیگر تعامل داشته باشند. آنها یک سنت شایان ستایش در ارائه یک سخنرانی نیمه طنز در مورد اینکه چرا جنگو بد است، دارند. این می تواند عضوی از جامعه جنگو یا شخصی باشد که روی FrameWork های وب رقیب کار می کند یا هر شخصیت برجسته ای باشد. در طول سالها، شگفتانگیز است که چگونه توسعهدهندگان جنگو این انتقادات را مثبت میگرفتند و در نسخههای بعدی آن را کاهش میدادند.
در اینجا خلاصهای از پیشرفتهای مربوط به چیزی است که زمانی در جنگو یک کاستی بود و نسخهای که در آن برطرف شد:
- کتابخانه جدید مدیریت فرم (Django 0.96)
- جداسازی ادمین از مدل ها (Django 1.0)
- پشتیبانی از چندین پایگاه داده (Django 1.2)
- مدیریت بهتر فایل های استاتیک (Django 1.3)
- پشتیبانی بهتر از منطقه زمانی (Django 1.4)
- مدل کاربر قابل تنظیم (Django 1.5)
- مدیریت بهتر تراکنش (جنگو 1.6)
- انتقال پایگاه داده داخلی (جنگو 1.7)
- موتورهای قالب چندگانه (جنگو 1.8)
- نحو ساده شده مسیریابی URL (Django 2.0)
با گذشت زمان، جنگو به یکی از اصطلاحی ترین پایگاه های کد پایتون در حوزه عمومی تبدیل شده است. کد منبع جنگو همچنین مکانی عالی برای یادگیری معماری یک FrameWork وب بزرگ پایتون است.
برای درک واقعی جنگو، باید زیر کاپوت را نگاه کنید و قسمت های متحرک مختلف داخل آن را ببینید. این می تواند هم روشنگر و هم طاقت فرسا باشد. اگر قبلاً با اطلاعات زیر آشنا هستید، ممکن است بخواهید از این بخش صرفنظر کنید:
نحوه پردازش درخواست های وب در یک برنامه معمولی جنگو
نمودار قبلی سفر ساده درخواست وب از مرورگر بازدیدکننده به برنامه جنگو و بازگشت را نشان می دهد. مسیرهای شماره گذاری شده به شرح زیر است:
- مرورگر درخواست را (در اصل یک رشته بایت) به وب سرور شما ارسال می کند.
- وب سرور شما (مثلاً Nginx) درخواست را به یک سرور رابط دروازه وب سرور (WSGI) (مثلا uWSGI) تحویل می دهد یا مستقیماً یک فایل (مثلاً یک فایل CSS) را از سیستم فایل ارائه می دهد.
- برخلاف وب سرور، سرورهای WSGI می توانند برنامه های پایتون را اجرا کنند. این درخواست یک فرهنگ لغت پایتون به نام
environ
را پر می کند و به صورت اختیاری، از چندین لایه میان افزار عبور می کند و در نهایت به برنامه جنگو شما می رسد. - URLconf (پیکربندی URL) ماژول موجود در
urls.py
پروژه شما، یک نمای را برای رسیدگی به درخواست بر اساس URL درخواستی انتخاب می کند. درخواست به HttpRequest، یک شی پایتون تبدیل شده است. - نمای انتخاب شده معمولاً یک یا چند مورد از کارهای زیر را انجام می دهد: a. از طریق مدل ها با پایگاه داده صحبت می کند. b. HTML یا هر پاسخ فرمت شده دیگری را با استفاده از Template ارائه می دهد c. یک متن ساده را بر میگرداند ( نشان داده نمیشود) d. در صورت وجود، یک exception بر میگرداند
- شیع
HttpResponse
به متن تبدیل (Render) میشود. - یک صفحه وب با رندر زیبا در مرورگر شما دیده می شود.
اگرچه جزئیات خاصی حذف شده است، این نمایش باید به شما در درک معماری سطح بالای جنگو کمک کند. همچنین نقشهایی را که اجزای کلیدی بازی میکنند، مانند مدلها، نماها و قالبها نشان میدهد. بسیاری از اجزای جنگو بر اساس چندین الگوی طراحی شناخته شده هستند.
چه چیزی بین کلمات نقشه ، داربست و نگهداری مشترک است؟ این اصطلاحات توسعه نرم افزار از دنیای ساخت و ساز ساختمان و معماری به عاریت گرفته شده است. با این حال، یکی از تأثیرگذارترین اصطلاحات از رساله ای در معماری و شهرسازی می آید که در سال 1977 توسط معمار برجسته اتریشی کریستوفر الکساندر و تیمش متشکل از موری سیلورستاین، سارا ایشیکاوا و چندین نفر دیگر نوشته شده است.
اصطلاح الگو پس از کار اصلی آنها، A Pattern Language: Towns, Buildings, Construction (جلد 2 در یک مجموعه پنج کتابی)، بر اساس بینش شگفت انگیزی که کاربران در مورد ساختمان های خود بیش از هر معمار دیگری می دانند، رایج شد. یک الگو به یک مشکل روزمره و راه حل پیشنهادی اما آزمایش شده آن اشاره دارد. کریستوفر الکساندر در این کتاب چنین می گوید:
"هر الگو یک مشکل را توصیف می کند که بارها و بارها در محیط ما رخ می دهد و سپس هسته راه حل آن مشکل را به گونه ای توصیف می کند که می توانید از این راه حل میلیون ها بار استفاده کنید، بدون اینکه هرگز آن را به همان روش انجام دهید. دو برابر."
برای مثال، الگوی بالهای نوری او توضیح میدهد که چگونه مردم ساختمانهایی با نور طبیعیتر را ترجیح میدهند و پیشنهاد میکند که ساختمان را به گونهای تنظیم کنید که از بال تشکیل شده باشد. این بال ها باید بلند و باریک باشند و هرگز بیش از 25 فوت عرض نداشته باشند. دفعه بعد که از قدم زدن در راهروهای طولانی یک دانشگاه قدیمی لذت بردید، از این الگو سپاسگزار باشید.
کتاب آنها شامل 253 الگوی عملی از این قبیل بود، از طراحی یک اتاق گرفته تا طراحی کل شهر. مهمتر از همه، هر یک از این الگوها نامی برای یک مسئله انتزاعی گذاشتند و با هم یک زبان الگو را تشکیل دادند.
به یاد دارید که اولین بار با کلمه déjà vu برخورد کردید؟ احتمالاً فکر کرده اید: "وای، من هرگز نمی دانستم که کلمه ای برای آن تجربه وجود دارد." به طور مشابه، معماران نه تنها قادر به شناسایی الگوها در محیط خود بودند، بلکه میتوانستند در نهایت آنها را به گونهای نامگذاری کنند که همتایان خود بتوانند آن را درک کنند.
در دنیای نرم افزار، اصطلاح الگوی طراحی به یک راه حل کلی قابل تکرار برای یک مشکل رایج در طراحی نرم افزار اشاره دارد. این رسمی سازی بهترین شیوه هایی است که یک توسعه دهنده می تواند از آن استفاده کند. مانند دنیای معماری، زبان الگو ثابت کرده است که برای برقراری ارتباط روش خاصی برای حل یک مشکل طراحی با برنامه نویسان دیگر بسیار مفید است.
مجموعه های مختلفی از الگوهای طراحی وجود دارد، اما برخی از آنها به طور قابل توجهی تاثیرگذارتر از بقیه بوده اند.
یکی از اولین تلاشها برای مطالعه و مستندسازی الگوهای طراحی، کتابی با عنوان *الگوهای طراحی: عناصر نرمافزار شی گرا قابل استفاده مجدد (Design Patterns: Elements of Reusable Object-Oriented Software) * توسط اریش گاما، ریچارد هلم، رالف جانسون و جان ولیسیدز بود که بعدها به گروه چهار نفر ( Gang of Four «GoF» ) معروف شد. ). این کتاب به قدری تأثیرگذار است که بسیاری 23 الگوی طراحی موجود در کتاب را برای خود مهندسی نرم افزار اساسی می دانند.
در واقع، الگوها عمدتاً برای زبانهای برنامهنویسی شی گرا ثابت نوشته شدهاند و نمونههایی از کد در C++ و Smalltalk داشتند. همانطور که به زودی خواهیم دید، برخی از این الگوها ممکن است حتی در سایر زبان های برنامه نویسی با انتزاعات بالاتر مانند پایتون مورد نیاز نباشند.
23 الگو به طور کلی بر اساس نوع خود به شرح زیر طبقه بندی شده اند:
-
الگوهای خلاقانه: این الگوها شامل کارخانه انتزاعی، الگوی سازنده، روش کارخانه، الگوی نمونه اولیه و الگوی تکتنه است.
-
الگوهای ساختاری: اینها شامل الگوی آداپتور، الگوی پل، الگوی ترکیبی، الگوی تزئینی، الگوی نما، الگوی وزن پرواز و الگوی پروکسی است.
-
الگوهای رفتاری: این الگوها شامل زنجیره مسئولیت، الگوی فرمان، الگوی مفسر، الگوی تکرارکننده، الگوی میانجی، الگوی یادگاری، الگوی مشاهده گر، الگوی حالت، الگوی استراتژی، الگوی الگو، و الگوی بازدیدکننده است.
در حالی که توضیح دقیق هر الگو خارج از محدوده این کتاب است، شناسایی برخی از این الگوهای موجود در خود پیادهسازی جنگو جالب خواهد بود:
| الگوی GoF | کامپوننت جنگو | توضیح | الگوی فرمان | HttpRequest | این یک درخواست در یک شی | | الگوی مشاهده گر | سیگنال ها | هنگامی که یک شی تغییر حالت می دهد، همه شنوندگان آن به طور خودکار مطلع و به روز می شوند | | روش قالب | نماهای عمومی مبتنی بر کلاس | مراحل یک الگوریتم را می توان با زیر طبقه بندی بدون تغییر ساختار الگوریتم دوباره تعریف کرد |
در حالی که این الگوها بیشتر مورد توجه کسانی است که درونیات جنگو را مطالعه می کنند، رایج ترین سؤالی که پرسیده می شود این است که خود جنگو تحت کدام الگو طبقه بندی می شود؟
مدل-ویو-کنترلر (MVC) یک الگوی معماری است که توسط Xerox PARC در دهه 70 اختراع شد. به عنوان چارچوبی که برای ساخت رابط های کاربری در Smalltalk استفاده می شود، در کتاب GoF در ابتدا به آن اشاره شد.
امروزه MVC یک الگوی بسیار محبوب در فریمورک های برنامه های وب است. یک نوع سوال رایج این است که آیا جنگو یک چارچوب MVC است یا خیر
پاسخ هم بله و نه است. الگوی MVC از جداسازی لایه ارائه از منطق برنامه حمایت می کند. به عنوان مثال، هنگام طراحی یک API وب سایت بازی آنلاین، ممکن است جدول امتیازات بالای یک بازی را به عنوان یک فایل HTML، XML یا مقادیر جدا شده با کاما (CSV) ارائه دهید. با این حال، کلاس مدل زیربنایی آن مستقل از نحوه ارائه نهایی داده ها طراحی می شود.
MVC در مورد کاری که مدل ها، نماها و کنترلرها انجام می دهند بسیار سخت است. با این حال، جنگو نگاه بسیار کاربردی تری به برنامه های کاربردی وب دارد. با توجه به ماهیت پروتکل HTTP، هر درخواست برای یک صفحه وب مستقل از هر درخواست دیگری است. چارچوب جنگو مانند یک خط لوله برای پردازش هر درخواست و آماده سازی پاسخ طراحی شده است.
جنگو این را معماری مدل-تمپلیت-ویو (MTV) می نامد. نگرانیها بین کلاسهای واسط پایگاه داده (مدل)، کلاسهای پردازش درخواست (نما) و زبان قالب برای ارائه نهایی (الگو) جدایی وجود دارد.
اگر این را با MVC کلاسیک مقایسه کنید، یک مدل با مدل های جنگو قابل مقایسه است. یک view معمولاً Templates جنگو است و کنترلر خود چارچوبی است که یک درخواست HTTP ورودی را پردازش می کند و آن را به تابع view صحیح هدایت می کند.
اگر این به اندازه کافی شما را گیج نکرده است، جنگو ترجیح میدهد که تابع callback را برای مدیریت هر URL یک تابع view نامگذاری کند. این، متأسفانه، به ایده الگوی MVC از دیدگاه مربوط نمی شود.
در سال 2002، مارتین فاولر الگوهای معماری برنامه های سازمانی را نوشت که حدود 40 الگوی را توصیف کرد که او اغلب در هنگام ساخت برنامه های سازمانی با آنها مواجه می شد.
برخلاف کتاب GoF که الگوهای طراحی را توصیف می کرد، کتاب فاولر در مورد الگوهای معماری بود. از این رو، آنها الگوها را در سطح بسیار بالاتری از انتزاع توصیف می کنند و تا حد زیادی زبان برنامه نویسی آگنوستیک هستند.
الگوهای فاولر به صورت زیر سازماندهی می شوند:
- الگوهای منطقی دامنه: این الگوها شامل مدل دامنه، اسکریپت تراکنش، لایه سرویس و ماژول جدول است
- الگوهای معماری منبع داده: اینها شامل دروازه داده ردیف، دروازه داده جدول، نگاشت داده و رکورد فعال است.
- الگوهای رفتاری شی-رابطه ای: این الگوها شامل نقشه هویت، واحد کار و بار تنبل است.
- الگوهای ساختاری شی-رابطه ای: این الگوها عبارتند از نگاشت کلید خارجی، نگاشت، نگاشت وابسته، نگاشت جدول انجمن، فیلد هویت، LOB سریال، ارزش جاسازی شده، نگاشتهای ارثی، ارث بری جدول تک، ارث بری جدول بتن، و ارث بری جدول کلاس.
- الگوهای نگاشت ابرداده شی رابطه ای: این الگوها عبارتند از Query Object، Metadata Mapping و Repository.
- الگوهای ارائه وب: اینها عبارتند از کنترل کننده صفحه، کنترلر جلو، کنترلر نمای مدل، نمای تبدیل، نمای الگو، کنترل کننده برنامه، و نمای دو مرحله ای
- الگوهای توزیع: اینها شامل شی انتقال داده و نما از راه دور است
- الگوهای همزمانی آفلاین: این الگوهای شامل قفل درشت دانه، قفل ضمنی، قفل آفلاین خوش بینانه و قفل آفلاین بدبینانه است.
- الگوهای وضعیت جلسه: اینها شامل وضعیت جلسه پایگاه داده، وضعیت جلسه مشتری و وضعیت جلسه سرور است.
- الگوهای پایه: این الگوها عبارتند از Mapper، Gateway، Layer Supertype، Registry، Value Object، Separated Interface، Money، Plugin، Case Special، Service Stub و Record Set.
دانستن تقریباً همه این الگوها هنگام طراحی یک برنامه جنگو مفید است. در واقع، وبسایت فاولر به آدرس http://martinfowler.com/eaaCatalog
یک کاتالوگ عالی از این الگوها به صورت آنلاین دارد. من به شدت توصیه می کنم آنها را بررسی کنید.
جنگو تعدادی از این الگوها را نیز پیاده سازی می کند. جدول زیر تعدادی از آنها را فهرست می کنددانستن تقریباً همه این الگوها هنگام طراحی یک برنامه جنگو مفید است. در واقع، وبسایت فاولر به آدرس http://martinfowler.com/eaaCatalog
یک کاتالوگ عالی از این الگوها به صورت آنلاین دارد. من به شدت توصیه می کنم آنها را بررسی کنید.
جنگو تعدادی از این الگوها را نیز پیاده سازی می کند. جدول زیر تعدادی از آنها را فهرست می کند:
الگوهای فاولر | کامپوننت های جنگو | توضیح |
---|---|---|
رکورد فعال | مدل های جنگو | دسترسی به پایگاه داده را کپسوله کنید و منطق دامنه را روی آن داده ها اضافه کنید |
وراثت جدول کلاس | وراثت مدل ها | هر موجودیت در سلسله مراتب به یک جدول جداگانه نگاشت می شود |
فیلد هویت | ID فیلد | برای حفظ هویت، یک فیلد ID پایگاه داده را در یک شی ذخیره می کند |
Template view | قالب های جنگو | رندر خروجی HTML بوسلیه تبدیل علامت ها و حروف |
بله حتما. الگوها همیشه کشف می شوند. مانند موجودات زنده، برخی جهش می یابند و الگوهای جدیدی را تشکیل می دهند، به عنوان مثال، انواع MVC مانند Model-view-presenter (MVP)، Hierarchical model-view-controller (HMVC) ، یا Model View ViewModel (MVVM).
الگوها نیز با گذشت زمان تکامل می یابند، زیرا راه حل های بهتری برای مشکلات شناخته شده شناسایی می شود. به عنوان مثال، الگوی Singleton زمانی به عنوان یک الگوی طراحی در نظر گرفته می شد، اما اکنون به دلیل حالت مشترکی که معرفی می کند، مشابه با استفاده از متغیرهای سراسری، به عنوان یک ضد الگو در نظر گرفته می شود. یک ضد الگو را می توان به عنوان راه حلی که معمولاً دوباره اختراع می شود، اما راه حلی بد برای یک مشکل تعریف کرد. برخی از کتابهای معروف دیگر که الگوهای فهرستنویسی دارند، معماری نرمافزار الگو محور (POSA) توسط Buschmann، Meunier، Rohnert، Sommerlad و Sta هستند. الگوهای ادغام سازمانی توسط هوپ و وولف. و طراحی سایت ها: الگوها، اصول و فرآیندها برای ایجاد یک تجربه وب مشتری محور توسط Duyne، Landay و Hong.
این کتاب الگوهای طراحی و معماری خاص جنگو را پوشش میدهد که برای توسعهدهنده جنگو مفید است. هر الگو به این صورت ارائه خواهد شد:
**نام الگو
عنوان نام الگو است. اگر یک الگوی شناخته شده باشد، از نام رایج استفاده می شود. در غیر این صورت، نام مختصر و خود توصیفی انتخاب شده است. نام ها مهم هستند، زیرا به ساخت واژگان الگو کمک می کنند. تمام الگوها دارای قسمت های زیر خواهند بود:
- مشکل: در اینجا به طور خلاصه به مشکل اشاره می شود
- راه حل: این راه حل(های) پیشنهادی را خلاصه می کند
- جزئیات مشکل: این موضوع زمینه مشکل را توضیح می دهد و احتمالاً مثالی را ارائه می دهد
- جزئیات راه حل: این راه حل (ها) را به طور کلی توضیح می دهد و نمونه ای از اجرای جنگو را ارائه می دهد
علیرغم کاربرد تقریباً جهانی آنها، الگوها نیز سهم خود را از انتقاد دارند. رایج ترین استدلال ها علیه آنها به شرح زیر است:
-
الگوها ویژگیهای زبان از دست رفته را جبران میکنند: پیتر نورویگ دریافت که 16 الگو از 23 الگو در الگوهای طراحی در زبانهای پویا مانند Lisp یا Python نامرئی یا سادهتر هستند. برای مثال، از آنجایی که توابع قبلاً در پایتون اشیاء هستند، ایجاد کلاسهای جداگانه برای پیادهسازی الگوهای استراتژی غیرضروری است.
-
الگوها بهترین شیوهها را تکرار میکنند: بسیاری از الگوها اساساً رسمیسازی بهترین شیوهها، مانند تفکیک نگرانیها هستند، و ممکن است زائد به نظر برسند. الگوها می توانند منجر به مهندسی بیش از حد شوند: پیاده سازی الگو ممکن است در مقایسه با راه حل ساده تر کارآمدتر و بیش از حد باشد.
-
الگوها می توانند منجر به مهندسی بیش از حد شوند: پیاده سازی الگو ممکن است در مقایسه با راه حل ساده تر کارآمدتر و بیش از حد باشد.
اگرچه برخی از انتقادات قبلی کاملاً معتبر است، اما بر اساس نحوه استفاده نادرست از الگوها است. در اینجا چند توصیه وجود دارد که می تواند به شما در درک بهترین روش استفاده از الگوهای طراحی کمک کند:
- بهتر است از الگوها برای بیان اینکه شما از یک رویکرد طراحی کاملاً درک شده پیروی می کنید استفاده می شود
- اگر زبان شما از راه حل مستقیم پشتیبانی می کند، الگو را پیاده سازی نکنید
- سعی نکنید همه چیز را از نظر الگوها بازسازی کنید
- از یک الگو فقط در صورتی استفاده کنید که ظریف ترین راه حل در زمینه شما باشد
- از ایجاد الگوهای جدید نترسید
به طور کلی، جامعه پایتون از اصطلاح پایتونیک برای توصیف یک کد اصطلاحی استفاده می کند. معمولاً به اصولی اشاره دارد که در The Zen of Python بیان شده است. که مانند یک شعر نوشته شده است، توصیف چنین مفهوم مبهمی بسیار مفید است.
** نکته: برای مشاهده Zen of Python سعی کنید این را در یک اعلان پایتون وارد کنید
.
علاوه بر این، توسعهدهندگان جنگو فلسفههای طراحی خود را در حین طراحی چارچوب در https://docs.djangoproject.com/en/dev/misc/design-philosophies/
به طور واضح مستند کردهاند.
در حالی که این سند فرآیند فکری پشت چگونگی طراحی جنگو را توضیح میدهد، اما برای توسعهدهندگانی که از جنگو برای ساخت برنامهها استفاده میکنند نیز مفید است. برخی از اصول مانند: Don't Repeat Yourself (DRY), loose coupling, and tight cohesion می توانند به شما کمک کنند تا برنامه های جنگو قابل نگهداری و اصطلاحی بیشتری بنویسید.
بهترین شیوه های جنگو یا پایتون پیشنهاد شده توسط این کتاب به روش زیر قالب بندی می شوند:
** نکته: از BASE_DIR
در settings.py
استفاده کنید و از کدگذاری نام دایرکتوری ها خودداری کنید.
در این فصل، ما به این موضوع پرداختیم که چرا مردم جنگو را نسبت به سایر چارچوب های وب، تاریخچه جالب آن و نحوه کارکرد آن انتخاب می کنند. ما همچنین الگوهای طراحی، مجموعه های الگوهای محبوب و بهترین شیوه ها را بررسی کردیم.
در فصل بعد، نگاهی به چند مرحله اولیه در آغاز پروژه جنگو خواهیم داشت، مانند جمع آوری نیازمندی ها، ساخت ماکت ها و راه اندازی پروژه.