مروری بر الگوی معماری MVC

MVC مخفف Model-View-Controller است و یک الگوی معماری نرم افزار است که معمولاً برای توسعه برنامه های نرم افزاری استفاده می شود. اگرچه MVC در ابتدا برای محاسبات دسکتاپ طراحی شده بود، اما به طور گسترده ای به عنوان طراحی برای برنامه های کاربردی وب جهانی در زبان های برنامه نویسی اصلی مورد استفاده قرار گرفت.

الگوی Model-View-Controller ابتدا در اواخر دهه 1970 توسط Trygve Reenskaug، دانشمند کامپیوتر نروژی، زمانی که او در Xerox PARC (مرکز تحقیقات پالو آلتو) کار می کرد، ایجاد شد. الگوی MVC برای کمک به جداسازی نگرانی‌های طراحی رابط کاربری از منطق برنامه کاربردی طراحی شده بود و توسعه، آزمایش و نگهداری نرم‌افزار را آسان‌تر می‌کرد.

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

الگوهای دیگری مشابه MVC مانند MVP (Model–View–Presenter) یا MVVM (Model-View-ViewModel) وجود دارد، اما اینها خارج از محدوده این مقاله هستند. در این مقاله، ما بر روی معماری سنتی MVC برای برنامه های کاربردی وب تمرکز خواهیم کرد.

اگر با فریمورک هایی مانند Laravel، Ruby on Rails یا Flask کار کرده اید، ممکن است قبلاً با معماری MVC آشنا باشید. این برنامه را به سه جزء مرتبط با هم تقسیم می کند:

مدل

Model اغلب یک جدول را در پایگاه داده یک برنامه نشان می دهد و مسئول خواندن و نوشتن داده ها و همچنین تداوم وضعیت برنامه است.

در MVC، مدل به گونه ای طراحی شده است که مستقل از View و Controller باشد. می توان آن را به طور جداگانه از سایر بخش های برنامه آزمایش و توسعه داد.

چشم انداز

View مسئول نمایش داده ها به کاربران و مدیریت تعامل کاربر است. در تفسیر سنتی الگوی MVC، View نباید مستقیماً با مدل ارتباط برقرار کند. کنترلر باید پس از دریافت اطلاعات از مدل در مورد هر گونه تغییر در داده، View را به روز کند.

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

کنترل کننده

Model و View از طریق کنترلرها به یکدیگر متصل می شوند. کنترلر مسئول دریافت و پردازش ورودی کاربر، دستکاری مدل (واکشی/ایجاد/به روز رسانی/حذف داده ها) و به روز رسانی View (بازگرداندن پاسخ مناسب برای ارائه) است.

نمایش تصویری MVC برای یک برنامه وب

در زیر نموداری از یک برداشت احتمالی از الگوی MVC برای یک برنامه وب ارائه شده است.

بیایید نگاهی دقیق تر به آنچه در اینجا رخ می دهد بیندازیم:

1. کاربر یک URL را در یک مرورگر وارد می کند و درخواستی را برای یک برنامه وب برای باز کردن یک صفحه خاص، در مورد ما، ارسال می کند https://website.com/pages. به طور مشابه، یک کاربر می تواند انواع دیگری از درخواست ها را ارسال کند، به عنوان مثال، درخواست POST از یک صفحه وب برای ایجاد یک رکورد جدید در پایگاه داده.

2. برای اینکه بدانیم کدام صفحه/پاسخ را بر اساس درخواست کاربر نشان دهیم، برنامه وب فهرستی از مسیرها دارد. اینها اساساً الگوهای URL مرتبط با صفحات مختلف هستند که برنامه سعی می کند با URL درخواستی مطابقت دهد. مسیرها با کنترل‌کننده‌ها یا بهتر است بگوییم با یک عملکرد خاص در داخل کنترلر که به عنوان کنش کنترلر شناخته می‌شود، مرتبط هستند. اگر برنامه یک مسیر منطبق پیدا کند (/صفحات در مورد ما)، عمل کنترل کننده مربوط به مسیر را فراخوانی می کند. اگر مسیر پیدا نشد، برنامه خطای 404 را برمی‌گرداند.

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

4. همانطور که قبلاً بحث شد، Model اغلب یک جدول را در پایگاه داده یک برنامه نشان می دهد، در مورد ما، PageModel با صفحات جدول پایگاه داده

5. مدل درخواستی برای خواندن یا نوشتن داده ها از پایگاه داده می دهد. پایگاه داده دستور مشخص شده را اجرا می کند، در مورد ما، تمام صفحات را از جدول صفحات واکشی می کند و نتیجه (داده ها) را به PageModel برمی گرداند.

6. PageModel داده های صفحات را به PagesController برمی گرداند.

7. کنترلر داده های دریافتی از Model را به View ارسال می کند. در نهایت، View صفحه درخواستی را با استفاده از داده های دریافتی از Controller ارائه می کند. View آخرین صفحه ای است که کاربر در مرورگر خود می بیند.

در پایان، امیدوارم این اطلاعات مفید بوده باشد، منتظر مطالب بیشتر باشید 🙂

منبع

1. Model–view–controller – ویکی پدیا

2. Trygve Reenskaug – ویکی پدیا