مرروری بر معماری MVC
نرم افزارهای وب معمولا اطلاعات رو از یه منبع اطلاعاتی میگیرن و به کاربر نمایش میدن و کاربر ممکنه آنها را تغییر بده و یا اطلاعات جدید ایجاد کنه که در نهایت توسط سیستم در بانک اطلاعاتی دخیره میشن . میشه عمده فعالیت یه نرم افزار وب رو توی این عملیاتها خلاصه کرد. ممکنه به دلیل ارتباط و جریان مداوم اطلاعات بین پایگاه داده (دیتابیس) و واسط گرافیکی (UI)، بخواید کدهای این دو بخش رو در کنار هم قرار بدید. البته این کار با هدف کم کردن حجم کد و بالابردن کارایی نرم افزار انجام میشه اما میتونه مشکلات زیادی به وجود بیاره. یکی از مشکلات این روش اینه که ، تغییرات مجدد در ظاهر سایت (UI) غیر ممکن میکنه (معمولا این تغییرات خیلی بیشتر از تغییراته لایه کنترل و منطق اتفاق میفته). یکی دیگه از مشکلات میتونه نیاز به استفاده یه بخش از لایه کنترل و منطق برنامه برای به روزرسانی بخشهای مختلف واسط گرافیکی باشه.
برای جداکردن بخشهای مختلف نرم افزار این دلایل رو داریم :
- معمولا تغییرات بر روی ظاهر برنامه نسبت به کدهای پردازش و منطق آن بسیار بیشتر است . ادغام این دو لایه باعث میشه کوچکترین تغییرات بر روی ظاهر ، کدهای بخش پردازش و منطق نرم افزار را نیز تحت تاثیر قرار دهد . این مشکل را میشه با جدا کردن این دو بخش و انتقال اطلاعات بین این دو ، حل کرد . اصطلاحا میگن thin-client ایجاد کنیم. به این معنی که کدهای مربوط به پردازش و منطق نرم افزار را از کدهای واسط کاربری UI (ظاهر سایت) جدا کنیم.
- این روزها نرم افزارهای زیادی رو میبینیم که اطلاعات مشابه رو به قالبها و روشهای مختلف نمایش میدن. برای مثال اطلاعاتی که به یک تحلیلگر اطلاعات نمایش داده میشه متفاوت از اطلاعاتی هست که به یک مدیر نمایش داده میشه. تحلیلگر اطلاعات میخواد ریز اطلاعات رو در ردیفهایی ببینه. اما مدیر توی دید اول فقط نمای نموداری از اطلاعات نیاز داره. نرم افزارهای با واسطهای گرافیکی قدرتمند امکان به روزرسانی آنی و در لحظه اطلاعات در نماهای مختلف رو فراهم میکنن.
- در طراحی وبسایت ، طراحی واسط گرافیکی (UI) یا همان Frontend ، به مجموعه مهارتهای متفاوتی نسبت به توسعه کدهای منطق برنامه یا همان Backend ، نیاز داره. معمولا افراد کمی هستن که مهارتهای هر دو مجموعه رو در حد اعلای خودش داشته باشن. وقتی این دو بخش از هم جدا بشن میتونیم کار توسعه نرم افزار رو در قالب یک تیم پیش ببریم و از مزایای داشتن تیم بهره مند بشیم.
- عملیاتهایی که در UI انجام میشن معمولا در دو حوزه قرار میگیرن: نمایش اطلاعات و ذخیره سازی اطلاعات. هنگام نمایش اطلاعات بخش منطق (Logic) نرم افزار اطلاعات مورد نیاز رو به واسط گرافیکی انتقال میده. و در زمان ذخیره سازی ، اطلاعات از بخش نمایش به بخش منطق برنامه انتقال داده میشه و ذخیره سازی اتفاق میفته و بدنبال آن بخش UI مجددا بروزرسانی میشه.
- طراحی واسط کاربری UI ، با توجه به نوع دستگاهی که وبسایت بر روی آن نمایش داده میشود (کامپیوتر ، تلفن های هوشمند و تبلتها،.. ) ممکن است کمی متفاوت باشند . اگر نیاز باشه نرم افزار وب رو برای دستگاه دیگه ای بازنویسی کنید، تغییرات در UI باعث میشه بخش زیادی از کدهای پردازش و منطق برنامه هم تغییر کنه. این موضوع میتونه باعث ایجاد خطاهای زیادی بشه. اما اگه این دو بخش به شکل خوش تعریفی از هم جدا بشن، هزینه و زمان برای طراحی بسترهای جدید نیز کاهش پیدا میکنه.
- تولید تست اتوماتیک برای واسط گرافیکی در حال حاضر کار بسیار دشوار و زمانبری هست. این موضوع در مورد کدهای پردازش و منطق ، با ابزارهایی که امروز داریم بسیار ساده تر شده. بنابراین جداکردن این دو بخش باعث افزایش امکان تست پذیری نرم افزار میشه .
الگوی معماری MVC بخشهای مدلسازی دامنه (domain model)، نمایش (presentation) و منطق تجاری (business logic) رو به سه بخش تقسیم میکنه.
مدل (Model): روند انتقال داده را مدیریت میکند، درخواستهایی که در مورد وضعیت مدل، مثل تغییر فیلدی از یه رکورد، وجود دارد را پاسخ میده (معمولا از سمت view) و عملیاتهایی که موجب تغییر وضعیت خودش میشه رو انجام میده (معمولا از سمت کنترلر).
نمایش (View): نمایش اطلاعات به کاربر را مدیریت میکند.
کنترلر (Controller): بخش ورودیهای کاربر رو مدیریت میکنه . و مدل و View مربوط به آن را فراخوانی و داده ها را از مدل به لایه نمایش اطلاعات (View) انتقال میده.
توی این تعریف میبینید که هر دو بخش کنترلر و view به مدل وابسته هستن. اما در مورد مدل این وابستگی وجود نداره و از هر دو عنصر دیگه مستقل عمل میکنه. این ویژگی میتونه به تولید بخش مستقل که قابلیت تست بالایی داره منجر بشه. توی نرم افزارهای وب این تفکیک و جداسازی به خوبی دیده میشه و قابل لمس هست. اما توی نرم افزارهایی که طراحی UI و کد های پردازش و منطق در هم تنیدگی دارن یا اصطلاحا rich-client ها این موضوع دیده نمیشه.
MVC یا Model-View-Controller یک الگوی طراحی پایه برای جداسازی بخش واسط کاربری UI از قسمت های پردازشی و منطقی برنامه می باشد.
انواع پیاده سازیها
آقای Steve Burbeck توی کتاب “(How to use Model-View-Controller (MVC” دو نوع MVC رو معرفی میکنه: فعال (Active) و غیرفعال (Passive).
مدل غیرفعال زمانی استفاده میشه که کنترلر وظیفه اعمال تغییرات روی مدل رو انجام میده. کنترلر مدل رو تغییر میده و اطلاعات آن را به view انتقال میده . توی این سناریو مدل کاملا از view و کنترلر جداست. این مدل پیاده سازی باعث میشه که مدل هیچ راهی برای اعلام تغییرات خودش نداشته باشه.
مدل فعال (Active) زمانی استفاده میشه که وضعیت (state) مدل بدون دخالت کنترلر هم تغییر میکنه.
یکی از دلایل استفاده از مدل MVC جداکردن مدل از view هست. اگر مدل میتونه view رو از تغییرات آگاه کنه، این شاید به معنی وابستگی دوباره باشه و ما از این وابستگی دوری میکنیم. الگویی برای رفع این وابستگی به نام Observer وجود داره. این الگو مکانیزمی برای آگاه کردن اشیاء مجموعه بدون ایجاد وابستگی ارائه میکنه. شی view، اینترفیس Observer رو پیاده سازی میکنه و به مدل اضاف میکنه. مدل لیست نمونه هایی که برای دریافت تغییرات توی لیست ثبت شدن رو دنبال میکنه. با تغییر وضعیت، مدل لیست رو پیمایش میکنه و تمامی نمونه های ثبت شده رو از تغییر آگاه میکنه. این رویکرد رو با عنوان publish-subscriber میشناسن. توی این روش مدل نیازمند هیچ دانشی در مورد viewها نیست. توی سناریوهایی که کنترلرها هم باید از تغییرات مدل آگاه بشن، تمامی کنترلرها هم باید اینترفیس Observer رو پیاده سازی کنن و برای آگاهی از تغییرات خودشون رو به لیست مدل اضاف کنن. مواردی هستن که تعداد viewها بسیار زیاد هستن، راه حل در این روش میتونه تعریف موضوعها و دسته های مختلف از Observerها و لیستها باشه که هرکدوم نوعی از تغییرات مدل رو توصیف میکنن. و هر view میتونه توی دسته تغییراتی که نیاز به آگاه شدن از اون داره ، ثبت نام کنه.
توی تصویر میتونید ساختار MVC فعال رو با استفاده از الگوی Observer ببینید.
روال آگاه کردن view از تغییرات مدل توسط Observer توی تصویر زیر نشون داده شده.
تست پذیری
وقتی از معماری MVC استفاده میکنید تست پذیری بخش Back-end به شدت افزایش پیدا میکنه. هر چند ایجاد تستهای اتوماتیک برای اجزا و عناصر واسط گرافیکی یا front-end هنوز کار دشواری هست، اما این جداکردن اجزا و بخشها میتونه کمک بزرگی یرای افزایش تست پذیری باشه. برای انجام تستهای مختلف ابزارهای کاربردی زیادی هم به وجود اومدن که زمان تست رو به شدت کاهش میدن و میزان اعتماد به بخشهای مختلف نرم افزار رو بالاتر میبرن.
عناصر الگوی معماری MVC در فریمورک لاراول
فریمورک لاراول براساس معماری MVC پایه ریزی شده است . نرم افزارهای وب ، توسعه داده شده با لاراول بطور کامل هر سه جزء معماری MVC را دارا می باشند.
وقتیکه یک درخواست به لاراول ارسال میشه ، در لایه اول درخواست به موتور مسیریابی (Routing Engine) فرستاده میشه. مسیریاب این در خواست رو پردازش میکنه و به متد و کنترلر (Controller & Action) مناسب و متناسب میفرسته.
در این مرحله کنترلر جریان درخواست رو به عهده میگیره. گاهی کنترلر یه view رو نمایش میده، View قالبی است که به HTML تبدیل میشه و به مرورگر بر میگرده. در مورد سایتهای داینامیک، کنترلر بعد از تبادل اطلاعات با مدل (Model) وارد تعامل میشه. مدل یک کلاس PHP و نماینده یک عنصر در دامنه اطلاعات نرم افزار (مانند کاربر، یا پست بلاگ) هست. مدل مسئول تعامل با پایگاه داده هست. بعد از اینکه اطلاعات لازم از مدل دریافت شد، کنترلر View نهایی رو پردازش میکنه و یک صفحه وب کامل رو به مرورگر کاربر میفرسته.
لاراول معماری MVC را در پوشه های مختلف دسته بندی و از هم تفکیک میکنه.
آخرین دیدگاه‌ها