مدل-نما-کنترل‌گر

بندانگشتی|350px|معماری مدل-نما-کنترل‌گر
در مهندسی نرم‌افزار، **مدل-نما-کنترل‌گر** یا **ام‌وی‌سی** (Model–view–controller - MVC) به یک الگوی معماری نرم‌افزار گفته می‌شود.

الگوی ساختاری ام‌وی‌سی به جداسازی داده‌های کاربرد (از جملهٔ محتویات بخش مدل) از مؤلفه‌های ارائه شده به‌صورت گرافیکی (بخش نما) و منطق مربوط به پردازش ورودی‌ها (بخش کنترل‌گر) اقدام می‌نماید.

هدف الگوی ساختاری ام‌وی‌سی صرفاً یکپارچگی در ساختار نرم‌افزار است و به کمک آن بدست‌گیری نرم‌افزار در راستای مدیریت و گسترش به سادگی انجام می‌گیرد.

## تاریخچه
در یکی از بینش‌های ابتدایی در ابتدای گسترش و پیشرفت واسط گرافیکی کاربر MVC به عنوان یکی از راه حل‌ها و بکارگیری ساختار نرم‌افزاری به عنوان یک وظیفه انتخاب شد.
Trygve Reenskaug در حین ملاقات زروکس (مرکز تحقیقاتی پالو آلتو) در ۱۹۷۰ , MVC را در Smalltalk-76 معرفی کرد. در سال ۱۹۸۰ جیم اتوف و چند نفر دیگر یک ورژن از MVC را برای کتابخانهٔ کلاس Smalltalk-80 معرفی کردند و بعداً در سال ۱۹۸۸ در جورنال ابجکت تکنولوژی MVC را به عنوان یک مفهوم کلی معرفی کرد. MVC به‌طور پیوسته در حال پیشرفت بوده و موضوع‌های گوناگونی مانند hierarchical model-view-controller(JMVC) و model-view-adapter(MVA) و model-view-presenter(MVP) و model-view-viewmodel(MVVM) و MVCهای تطبیق داده شدهٔ دیگری را در موضوع‌های مختلف ایجاد کرده.
استفاده از MVC در وب اپلیکیشن‌ها بعد از معرفی وب ابجکت‌ها ی apple که در واقع با Objective-C که عمدتاً از Smalltalk گرفته شده بود نوشته شده بود در سال ۱۹۹۶ به صورت انفجاری افزایش یافت و به قوی تر شدن اصول MVCکمک کرد. بعداً روند MVC توسط توسعه دهندگان جاوا معروف شد وقتی وب ابجکت‌ها به جاوا مربوط شدند. فریم وورک‌های بعدی جاوا مانند Spring(در اکتبر ۲۰۰۲ منتشر شد) رابطهٔ جوا و MVC را قوی تر کرد. معرفی فریم وورک‌ها Django (ژوئیه ۲۰۰۵ برای پایتون) و Rails (دسامبر ۲۰۰۵ برای روبی) هر دو تأکید روی نظم دادن سریع داشتند و شهرت MVC را در خارج از محیط سنتی افزایش داد. در حال حاضر MVC frameworkها سهم بزرگی از بازار را که مرتبط با non MVC Tollkit هست را دارد.

## مرور کلی
گرچه‌ام‌وی‌سی گونه‌های بسیار دارد، کنترل جریان عموماً به صورت زیر است:
# کاربر به نوعی با میانجی کاربردی در اندر کنش است (برای مثال با فشردن دکمه ماوس).
# کنترل گر رویداد وارده از میانجی کاربردی را معمولاً از طریق یک کنترل گر رویداد ثبت شده یا callback کنترل می‌کند و رویداد را به یک عمل مناسب کاربری قابل فهم برای مدل تبدیل می‌کند.
# کنترل گر، مدل عمل کاربری را اعلام می‌کند که احتمال دارد منجر به تغییری در وضعیت مدل شود. (برای مثال کنترل گر، سبد خرید کاربر را به روز می‌رساند).
# یک نما، از مدل به منظور تولید یک واسط کاربری مناسب پرس و جو می‌کند. نما داده خودش را از مدل می‌گیرد. در برخی پیاده‌سازی‌ها کنترل گر ممکن است دستورالعملی عمومی به نما بدهد تا خودش را بارگذاری کند. در سایر پیاده‌سازی‌ها نما به‌طور خودکار توسط مدل از تغییرات در ناظر وضعیت مطلع می‌شود که نیازمند به روزرسانی صفحه است.
# واسط کاربری منتظر کنش کاربردی بیشتری می‌ماند که چرخه کنترل جریان را از نو آغاز می‌کند.

بعضی از پیاده‌سازی‌ها مانند فرم‌های کنسرسیوم وب جهان‌شمول از مفهوم نمودار وابستگی نیز برای خودکار کردن نماها زمان تغییر مدل استفاده می‌کنند.

هدف ام‌وی‌سی -با جداسازی مدل و نما- کاهش پیچیدگی طراحی الگوریتم و افزایش نرمی و نگهداشت‌پذیری کد مبدأ است. همچنین ام‌وی‌سی برای ساده‌سازی طراحی سیستم‌های خودرای و خودمدیریتی استفاده می‌شود.

## توضیحات
مانند بقیهٔ معماری نرم‌افزارها MVC راه حل اصلی یک مشکل است در حالی که می‌تواند خود را با هر سیستمی وفق دهد. معماری MVC با یک شرح سنتی به صورت زیر است:
اجزا:
مدل: قسمت اصلی و مرکزی است که رفتار اپلیکیشن را در قالب problem domain (دامنهٔ مشکل) اظهار می‌کند و از واسط کاربری مستقل است و به‌طور مستقیم داده و منطق وقوانین اپلیکیشن را مدیریت می‌کند.
دید(view): دید می‌تواند هر نمایشی از خروجی اطلاعات باشد مثل یک چارت یا دیاگرام. چند دید برای اطلاعات یکسان ممکن است برای مثال یک بار چارت برای مدیر و یک تولبار برای حسابداران.
کنترلر: کنترلر ورودی‌ها را می‌پذیرد و برای مدل یا دید به فرمان تبدیل می‌کند.
برهم کنش:
به علاوه برای تقسیم اپلیکیشن به سه قسمت، طراحی مدل و دید و کنترلر برهم کنش بین ان‌ها را مشخص می‌کند.
یک مدل(model) دادهٔ بازیابی شده از دستور کنترلر و نمایش داده شده در دید را ذخیره می‌کند.
یک دید(view) بر اساس تغییر در مدل خروجی را به کاربر می‌دهد.
یک کنترلر می‌تواند با فرستادن دستور به مدل وضعیت مدل را ارتقا دهد (تغییر یک سند). همچنین می‌تواند فرمان‌ها را به دیدهای مرتبط بفرستد تا حضور دید را د مدل تغییر دهد.

## فایده‌ها و زیان‌ها
فایده‌های MVC:

۱-قابلیت پیشرفت دادن هم‌زمان:
یعنی هم‌زمان چند نفر می‌توانند روی مدل و کنترلر و دیدها یا همان view کار کنند.

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

# هدایت یا دنبال کردن کد: هدایت یا دنبال کردن فریم وورک می‌تواند پیچیده باشد زیرا به این نیاز است که کاربر خود را با ضوابط و معیارهای ساختاری MVC وفق دهد.
# سازگاری چند ساختاری: خصوصیت چند ساختاری بودن باعث پراکندگی و ناسازگاری میان اجزا می‌شود بنا بر ای نیاز است که کسانی که آن را پیشرفت می‌دهند سازگاری و هماهنگی میان اجزا حفظ شود.
# کسانی که از MVC استفاده می‌کنند باید در چند زمینهٔ تکنولوژی مهارت داشته باشند.
## منابع

## پیوند به بیرون
* برخی از فریم ورکهای قدیمی PHP از سال ۲۰۰۳ که پیش تر روی ویکی‌پدیا مطرح شده بودند

رده:الگوهای طراحی نرم‌افزار
رده:الگوی معماری (علم رایانه)
رده:معماری نرم‌افزار