این مطالب بخشی از مجموعه "مقدمه ای بر توسعه سازمانی" است. مقالات قبلی:
در این مقاله با چیزی به نام MVC آشنا خواهیم شد. ما در مورد چیستی MVC صحبت خواهیم کرد، تاریخچه آن را لمس خواهیم کرد، ایده ها و مفاهیم اساسی موجود در MVC را بررسی خواهیم کرد، نگاهی گام به گام به نحوه تقسیم یک برنامه به ماژول های Model، View و Controller خواهیم داشت، برنامه وب کوچک با استفاده از Spring Boot، و با استفاده از Spring MVC به عنوان مثال، ببینید چگونه داده ها از کد جاوا به صفحات HTML ارسال می شود. برای درک این متریال باید با الگوهای طراحی به خصوص ناظر و نما آشنا باشید. و با درخواست ها و پاسخ های HTTP آشنا باشید، اصول HTML را درک کنید و یادداشت های جاوا را بدانید. یک فنجان قهوه و میان وعده بخورید و راحت باشید. شروع کنیم.
از همه اینها، می توانیم یک نتیجه منطقی بگیریم. یک سیستم پیچیده باید به ماژول ها تقسیم شود. اجازه دهید به طور خلاصه مراحل رسیدن به این جداسازی را شرح دهیم.
و اینگونه است که به یک برنامه کاربردی متشکل از سه ماژول به نامهای مدل، view و controller میرسیم. بیایید خلاصه کنیم:
- در مورد شبکه
- در مورد معماری نرم افزار
- درباره HTTP/HTTPS
- در مورد اصول اولیه Maven
- درباره servlets (نوشتن یک برنامه وب ساده)
- در مورد ظروف سرولت

تاریخچه MVC
ایده های پشت MVC توسط Trygve Reenskaug هنگام کار در Xerox PARC در اواخر دهه 1970 فرموله شد. در آن روزها، کار با کامپیوتر مستلزم مدرک تحصیلی و مطالعه مداوم اسناد حجیم بود. وظیفه ای که توسط Reenskaug به همراه گروهی از توسعه دهندگان بسیار قوی حل شد، ساده کردن تعامل یک کاربر معمولی با رایانه بود. ایجاد ابزارهایی ضروری بود که از یک طرف فوق العاده ساده و قابل درک باشد و از طرف دیگر امکان کنترل رایانه ها و برنامه های کاربردی پیچیده را فراهم کند. Reenskaug روی تیمی کار کرد که یک رایانه لپتاپ "برای کودکان در هر سنی" توسعه داد - Dynabook و همچنین زبان SmallTalk تحت رهبری آلن کی. آن زمان بود که مفاهیم یک رابط دوستانه مطرح شد. از بسیاری جهات، کار انجام شده توسط Reenskaug و تیمش بر تکامل حوزه فناوری اطلاعات تأثیر گذاشت. در اینجا یک واقعیت جالب وجود دارد که مستقیماً در مورد MVC صدق نمی کند، اما اهمیت این پیشرفت ها را نشان می دهد. آلن کی گفت : "وقتی برای اولین بار به اپل رسیدم، یعنی در سال 84، مک از قبل عرضه شده بود و نیوزویک با من تماس گرفت و نظرم را در مورد مک پرسید. من گفتم: "خب، مک اولین کامپیوتر شخصی است. آنقدر خوب است که مورد انتقاد قرار گیرد. بنابراین، پس از اعلام آیفون در سال 2007، آن را پیش من آورد و به من داد. او گفت: "آلن، آیا این به اندازه ای خوب است که مورد انتقاد قرار بگیرم؟" و من گفتم: "استیو، اندازه آن را به اندازه یک تبلت بساز تا تو بر جهان حکومت کنی." پس از 3 سال، در 27 ژانویه 2010، اپل آی پد را با قطر 9.7 اینچ معرفی کرد. به عبارت دیگر، استیو جابز تقریباً دقیقاً به توصیه آلن کی عمل کرد. پروژه Reenskaug به مدت 10 سال به طول انجامید. اما اولین انتشار در مورد MVC پس از 10 سال دیگر منتشر شد. مارتین فاولر، نویسنده چندین کتاب و مقاله در زمینه معماری نرمافزار، اشاره میکند که MVC را با استفاده از نسخهای از Smalltalk مطالعه کرده است. زیرا برای مدت طولانی اطلاعاتی در مورد MVC از منبع اصلی وجود نداشت و به چند دلیل دیگر تعداد زیادی تفسیر مختلف از این مفهوم ظاهر شد. در نتیجه، بسیاری MVC را یک الگوی طراحی می دانند. کمتر رایج، MVC یک الگوی ترکیبی یا ترکیبی از چندین الگو نامیده می شود که با هم کار می کنند تا برنامه های کاربردی پیچیده ایجاد کنند. اما همانطور که قبلا ذکر شد، MVC در واقع در اصل مجموعه ای از ایده ها/اصول/رویکردهای معماری است که می تواند به روش های مختلف با استفاده از الگوهای مختلف اجرا شود... در ادامه، ایده های اصلی تعبیه شده در مفهوم MVC را در نظر خواهیم گرفت.MVC: ایده ها و اصول اساسی
- VC مجموعه ای از ایده ها و اصول معماری برای ساخت سیستم های اطلاعاتی پیچیده با رابط کاربری است
- MVC مخفف عبارت Model-View-Controller است

مرحله 1. منطق تجاری برنامه را از رابط کاربری جدا کنید
ایده اصلی MVC این است که هر برنامه کاربردی با رابط کاربری را می توان به 2 ماژول تقسیم کرد: یک ماژول مسئول پیاده سازی منطق تجاری و رابط کاربری. ماژول اول عملکرد اصلی برنامه را پیاده سازی می کند. این ماژول هسته سیستم است که مدل دامنه برنامه در آن پیاده سازی می شود. در پارادایم MVC این ماژول حرف M یعنی مدل است. ماژول دوم کل رابط کاربری را پیاده سازی می کند، از جمله منطق نمایش داده ها به کاربر و مدیریت تعامل کاربر با برنامه. هدف اصلی این جداسازی این است که اطمینان حاصل شود که هسته سیستم ("مدل" در اصطلاحات MVC) می تواند به طور مستقل توسعه و آزمایش شود. پس از انجام این جداسازی، معماری برنامه به صورت زیر است:
مرحله 2 از الگوی مشاهده گر برای مستقل کردن مدل و همگام سازی رابط های کاربر استفاده کنید
در اینجا ما 2 هدف داریم:- دستیابی به استقلال حتی بیشتر برای مدل
- همگام سازی رابط های کاربری
مرحله 3 رابط را به view و controller جدا کنید
ما به تقسیم برنامه به ماژول ها ادامه می دهیم، اما اکنون در یک سطح پایین تر در سلسله مراتب. در این مرحله، رابط کاربری (که در مرحله 1 به یک ماژول مجزا تقسیم کردیم) به یک view و یک کنترلر تقسیم می شود. ترسیم یک خط دقیق بین نما و کنترلر دشوار است. اگر بگوییم نما همان چیزی است که کاربر می بیند و کنترلر مکانیزمی است که به کاربر اجازه می دهد با سیستم تعامل داشته باشد، ممکن است به یک تناقض اشاره کنید. عناصر کنترلی، مانند دکمه های صفحه وب یا صفحه کلید مجازی روی صفحه نمایش تلفن، اساساً بخشی از کنترلر هستند. اما آنها به اندازه هر قسمتی از نما برای کاربر قابل مشاهده هستند. آنچه ما در اینجا واقعاً در مورد آن صحبت می کنیم، جداسازی عملکردی است. وظیفه اصلی رابط کاربری تسهیل تعامل کاربر با سیستم است. این بدان معنی است که رابط فقط 2 عملکرد دارد:- خروجی و نمایش راحت اطلاعات سیستم به کاربر
- اطلاعات و دستورات کاربر را وارد کنید (آنها را به سیستم منتقل کنید)

- طبق اصول پارادایم MVC، یک سیستم باید به ماژول ها تقسیم شود.
- مهم ترین و مستقل ترین ماژول باید مدل باشد.
- مدل هسته اصلی سیستم است. توسعه و آزمایش آن به طور مستقل از رابط کاربری باید امکان پذیر باشد.
- برای رسیدن به این هدف، در مرحله اول تقسیم، باید سیستم را به یک مدل و رابط کاربری تقسیم کنیم.
- سپس، با استفاده از الگوی مشاهدهگر، استقلال مدل را تقویت کرده و رابطهای کاربری را همگامسازی میکنیم.
- مرحله سوم این است که رابط کاربری را به یک کنترلر و نمای تقسیم کنید.
- تمام آنچه برای دریافت اطلاعات کاربر در سیستم مورد نیاز است در کنترلر است.
- تمام آنچه برای ارائه اطلاعات به کاربر مورد نیاز است در نمای است.
کمی در مورد نحوه تعامل نما و کنترلر با مدل
با وارد کردن اطلاعات از طریق کنترلر، کاربر مدل را تغییر می دهد. یا حداقل، کاربر داده های مدل را تغییر می دهد. هنگامی که کاربر اطلاعات را از طریق عناصر رابط (از طریق view) دریافت می کند، کاربر در حال دریافت اطلاعات در مورد مدل است. چگونه این اتفاق می افتد؟ نما و کنترلر با چه وسیله ای با مدل تعامل دارند؟ به هر حال، کلاسهای view نمیتوانند مستقیماً متدهای کلاسهای مدل را برای خواندن/نوشتن دادهها فراخوانی کنند. در غیر این صورت نمیتوانیم بگوییم که مدل مستقل است. مدل مجموعه ای از کلاس های نزدیک به هم است که نه view و نه کنترل کننده نباید به آن دسترسی داشته باشند. برای اتصال مدل به نمای و کنترلر باید الگوی طراحی نما را پیاده سازی کنیم. نمای مدل لایه ای بین مدل و رابط کاربری است که از طریق آن نما داده های فرمت شده را به راحتی دریافت می کند و کنترلر با فراخوانی روش های لازم روی نما، داده ها را تغییر می دهد. در نهایت همه چیز به این صورت است:
GO TO FULL VERSION