MVC چیست؟ (قسمت دوم)
ادامه از قسمت اول
توی این قسمت مواردی رو که هنگام اعمال معماری MVC باید رعایت بشه توضیح میدم. اگه مستقیما وارد این مقاله شدید بهتون پیشنهاد میکنم که قبل از ادامه مطالعه به سراغ قسمت اول برید و با دقت اون رو بخونید چون توی این مقاله فرض کردم که شما قسمت اول رو خوندید.
آدرس دهی و URL ها
گرچه در تئوری، MVC باید بدون نقص در تمام برنامه های کامپیوتری پیاده سازی بشه اما اجرا اون در وب اپلیکیشن ها یه سری چالش داره. اولین مشکل این معماری با آدرس دهی URL ها است. در حقیقت وقتی MVC ابداع شد هیچکس به URL ها فکر نکرده بود و وقتی با پیشرفت تکنولوژی اینترنت همه گیر شد این معماری هم باید خودش رو با وب اپلیکیشن ها تطبیق می داد.
خوب حالا چطور باید این مشکل URL ها رو حل کرد؟ یه راه حل اینه که آدرس تمامی URL هایی رو که وب سایت ما داره به همراه اطلاعاتی رو که نشون میده هر URL چه Model ، View و یا Controller رو نیاز داره یکجا ذخیره کنیم. سپس هرگاه کاربر صفحه ای رو درخواست کرد، سیستم URL و کامپوننت های مورد نیاز اون رو بارگذاری و اجرا میکنه. این راه حل برای یک وب سایت استاتیک و یا یک وب سایت ساده که نیاز به آدرس دهی داینامیک (Dynamic URL’s) نداره بسیار کاربردیه. برای مثال :
URL ما چیزی شبیه به اینه :
example.com/index.php ?page=about
و یا
example.com/index.php ?page=portfolio
در اینجا سیستم، Model ، View و Controller صفحه درخواست شده رو بارگذاری میکنه. اگر پارامتر URL عبارت about باشه، صفحه about نمایش داده میشه و اگر پارامتر portfolio باشه صفحه portfolio.
این یه مثال خیلی ساده از آدرس دهی استاتیک بود که گرچه به سادگی پیاده سازی میشه اما نقاط ضعف خودش رو هم داره. مهمترین اشکال این روش اینه که در مقیاس های بزرگ کار باهاش خیلی سخت میشه چون تمامی صفحات وب سایت به همراه کامپوننت های مورد نیازشون باید توی آرایه ها ذخیره بشن.
راه حل دیگه اینه که اجازه بدیم پارامترهای URL تکلیف اینکه هر صفحه از چه کامپوننت هایی از Model ، View و Controller ها استفاده میکنه رو مشخص کنن. در مثال بالا ما اسم کلاس رو از یه آرایه استخراج کردیم، که بصورت استاتیک ذخیره شده بود. عوض کردن این آرایه با المان ها، آدرس دهی استاتیک (Static Routing) ما رو تبدیل به آدرس دهی داینامیک (Dynamic Routing) میکنه.
ما بر اساس پارامترهای URL به key های آرایه دست پیدا میکنیم اما کلاس ها و کامپوننت های مرتبط قبلا تعریف شده اند و نمیتوانیم value های مربوط به key ها رو دستکاری کنیم. با این محدودیت سوال اینجاست که اصولا چرا چنین کاری انجام میدیم؟ جواب اینه که لازم نیست برای تمام بخش های سیستم کد بزنیم. میتونیم صفحات و بخش های مختلف رو فقط با ایجاد ارتباط بین Model، View و Controller بسازیم. برای مثال :
حالا URL ما باید به این شکل باشه :
example.com/index.php ?controller=controllername & model=modelname & view=viewname & action=actionname
قسمت action آدرس URL به سیستم میگه که کدام تابع رو از Controller اجرا کنه. به یاد داشته باشید وقتی این تابع، اطلاعات رو به Model ارسال میکنه در حقیقت به مدل میگه کدوم View و View action رو بارگذاری کنه. این میتونه پارامتر action یو آر ال باشه و یا بوسیله Controller مشخص بشه. به یاد داشته باشید که هرگز اجازه ندید که Controller مستقیما View رو بارگذاری کنه و یا مستقیما اطلاعاتی رو به اون بفرسته؛ این کارها باید فقط با مداخله Model و ورودی از طریق کاربر انجام بگیره.
هردو این راه حل ها که گفتیم نقاط ضعف و قوت خودشون رو دارند. آدرس دهی استاتیک (Static routing) ثبات بیشتری داره، به سرعت قابل اجراست و برنامه نویس کنترل بهتری روش داره. اما آدرس دهی داینامیک (Dynamic routing) باعث میشه که در سیستم های بزرگ و با صفحات زیاد کار ما بهینه تر باشه.
در آدرس دهی داینامیک به نسبت آدرس دهی استاتیک وظیفه بیشتری بر دوش Controller گذاشته میشه و در صورت اجرا صحیح، Controller بازدهی بالاتری خواهد داشت.
کدهای چند بار مصرف (DRY) و قالب ها (Templates)
یکی از مهمترین دلایل برای استفاده از الگوی MVC اینست که سیستم تا جای ممکن مرتب و منظم باشد. برای رسیدن به این هدف باید تا حد ممکن تعداد instance ها را کم کرد. همه برنامه نویسان باتجربه روی این موضوع هم عقیده اند که بدترین چیز در یک اپلیکیشن تکرار یک کد به دفعات زیاد است. فلسفه کد های چند بار مصرف (Don’t Repeat Yoyrself) یا DRY این است که کد ها را تا جای ممکن ساده و عمومی بنویسیم تا بتوان از آن در جاهای مختلف استفاده کرد.
اصل DRY به ما میگوید که : "هر تکه از کد باید با یک تعریف ساده، غیر مبهم و معتبر داخل سیستم تعریف شود". هدف از بکار بردن اصل DRY اینست که برنامه نویس بتواند از تمام امکاناتی که در اختیار دارد استفاده کند که تا حد ممکن سیستم را بهینه و داینامیک بسازد. DRY میگوید که در شرایطی که نیاز است که یک کد مشابه در جاهای مختلف سیستم نوشته شود، به جای بازنویسی مکرر آن بهتر است که یک متد ایجاد کرد و هر جا لازم است آن متد را بکار برد. این روش باعث می شود که سیستم بهینه تر شده و چون این متد catch می شود در نتیجه زمان اجرا یا همان run time هم بهبود می یابد.
اجرای صحیح DRY تضمین می کند که تغییر در یک جزء از سیستم، قسمت های غیر مرتبط با آن جزء را تحت تاثیر قرار نخواهد داد. با این توضیح واضح است که DRY یک ستون اصلی در پیاده سازی معماری MVC است.
قالب ها (Templates)
کلمه قالب برای برنامه نویسانی که قبلا با Framework های برنامه نویسی وب اپلیکیشن مبتنی بر معماری MVC برخورد داشتن ممکنه سوالاتی ایجاد کنه اما بر اساس تعاریف جدید MVC ، قالب ها فقط میتونن توی قسمت View وجود داشته باشند. بصورت تئوری View وظیف پردازش و تکه تکه کردن اطلاعات فرستاده شده از طرف Model رو داره. بنابراین منطقی به نظر میرسه که اجزاء View یک قالب انتخاب کنند و اطلاعات رو بر اساس اون قالب نمایش بدن. این قالب قبلا ایجاد شده و منتظره که اطلاعات رو دریافت کنه و اون ها رو بر اساس دستوراتی به کاربر نمایش بده. در نظر داشته باشید که از هر قالبی استفاده کنید، اطلاعات باید آماده و نهایی باشند که بتونید اون ها رو از طریق قالب به کاربر نشون بدید. اگر در قالب غیر از نشان دادن اطلاعات آماده به کاربر، پردازش دیگه ای هم روی اون ها انجام بدید، این موضوع نشون دهنده اونه که MVC رو درست اجرا نکردید.
در اینجا یه مثال براتون میارم که View یک قالب رو لود میکنه و اطلاعات رو از طریق اون نمایش میده :
اینجا قالب از طریق Model ارائه میشه، اینجوری قالب بر اساس اینکه چه اطلاعاتی قراره ارائه بشه بصورت داینامیک تعیین میشه. این روش انتخاب قالب باعث میشه سیستم به درستی و بصورت بهینه توسعه پیدا کنه، همچنین به ما اجازه میده که برنامه نویسی بک اند رو از فرانت اند جدا کنیم و اینجوری فلسفه MVC به خوبی پیاده میشه.
خلاصه
معماری MVC زمانی که برای برنامه نویسان دسکتاپ ارائه شد یک انقلاب بوجود آورد. در مورد سناریو های مختلف برای پیاده سازی این معماری همیشه بحث های زیادی بین برنامه نویسان وجود داشته. این بحث ها و اختلاف نظر ها حتی زمانی که پای برنامه نویسی وب اپلیکیشن ها به میان اومده حتی بیشتر هم شده که این موضوع نشون دهنده اینه که افراد خیلی زیادی MVC رو برای توسعه وب اپلیکیشن ها بکار میبرن.
MVC بدلیل اینکه میان قسمت های مختلف یک سیستم، مرز بندی ایجاد میکنه و اجازه میده که برنامه نویسان بک اند و فرانت اند بصورت مجزا و مستقل عمل کنند خیلی مفید و سودمنده. به همه برنامه نویسانی که تا به حال از MVC استفاده نکردند اکیدا توصیه میکنم که وقت بزارن و این معماری رو یاد بگیرند و ازش استفاده کنند، بهشون قول میدم پشیمون نمی شوند.
