در عکس زیر نحوه ی تعامل سه عنصر (view,metod,controller) را نشان می دهد.
Model، نام بخشی از سیستم است که وظیفه نگهداری دائمی اطلاعات را برعهده دارد. این بخش باید امکان دسترسی به داده‌های ذخیره‌شده جهت نمایش به کاربر، یا دریافت و ذخیره‌سازی داده‌هایی که در اختیار آن قرار می‌گیرد را فراهم‌کند و نقش پُلی بین بخش View و بخش Controller را در درون سیستم ایفا می‌کند. یک جنبه بسیار مهم Model آن است که باید ازنظر فنی «کور» باشد؛ بدین‌معنا که هیچگونه ارتباط و آگاهی از آنچه که برسر داده در بخش‌های Controller و View می‌افتد، نداشته‌باشد. Model نه بخش‌های دیگر را فراخوانی می‌کند و نه منتظر پاسخ از آنها می‌ماند. تنها هدف آن، ذخیره‌سازی داده‌ها در رسانه فیزیکی (اعم از فایل یا بانک اطلاعاتی) یا خواندن و آماده‌سازی اطلاعات برای تحویل به بخش‌های دیگر است. البته Model را نمی‌توان به‌سادگی در حد پایگاه داده‌ها یا یک معبر به سایر سیستم‌های نگهداری اطلاعات (مثل فایل‌ها) کوچک‌شمرد. Model باید بعنوان دروازه‌بان داده‌ها عمل‌کند. سؤالی نپرسد اما تمامی درخواست‌هایی را که از کانال صحیح وارد می‌شوند، بپذیرد. در اغلب موارد، Model بعنوان پیچیده‌ترین بخش MVC، نقش هسته مرکزی آنرا نیز ایفا می‌کند؛ زیرا بدون آن، ارتباطی بین دو عنصر دیگر یعنی View و Controller برقرار نخواهد شد.
View مکانی است که داده‌هایی که از Model درخواست شده‌اند، به‌نمایش درآمده و خروجی نهایی آن توسط کاربر دیده می‌شود. در روش استاندارد کاربرد MVC، عنصر View بخشی از سیستم است که کد HTML در آن تولید و نمایش داده می‌شود. همچنین View محیطی را برای انجام عملیات توسط کاربر فراهم می‌کند و سپس، این عملیات به Controller منتقل می‌شوند تا به آنها پاسخ مناسب داده‌شود. مثال ساده‌ای از این روش، دکمه‌ای است که توسط View تولید می‌شود و وقتی کاربر برروی آن کلیک می‌کند، عملیاتی در Controller اتفاق می‌افتد. برخی باورهای اشتباه درباره عنصر View به‌خصوص دربین توسعه‌دهندگان وب که از MVC استفاده می‌کنند، رایج است. برای مثال، بسیاری از آنها به‌اشتباه فکر می‌کنند که View هیچگونه ارتباط مستقیمی با Model ندارد و تمام داده‌های موردنیاز جهت نمایش توسط View، ازطریق Controller ارسال می‌شود. درحقیقت، این روند با اصول MVC ناسازگاری کامل دارد اما متأسفانه این روند تا جایی رواج داشته‌است که در کتاب‌های آموزش MVC و حتی در برخی از فریمورک‌های معروف (مثل CakePHP) نیز از آن استفاده شده است. بعلاوه، توصیف View بعنوان یک فایل قالب نیز اشتباه است. هرچند، متأسفانه این باور نیز نه به‌صورت فردی بلکه دربین انبوهی از توسعه‌دهندگان و نویسندگان رایج است و منجر به یادگیری MVC به‌صورت اشتباه و در مرحله بعد، تدریس آن بصورت نادرست می‌شود. البته خوشبختانه در فریمورک‌های جدید و مدرن، این مسئله اصلاح شده‌است. بنابراین، همان‌طور که اشاره‌شد، داده‌های View ازطریق Controller تأمین نمی‌شوند و همان‌طور که قبلاً اشاره شد، هیچگونه ارتباط مستقیمی بین View و Controller وجود ندارد و Model نقش پُل بین آنها را ایفا می‌کند.
عنصر آخر از این عناصر سه‌گانه، Controller است. وظیفه آن، مدیریت داده‌های وارد (ارسال) شده توسط کاربر و بروز رسانی اطلاعات توسط Model است. شاهرگ حیاتی Controller کاربر است. بدون تعاملات کاربر، Controller هیچ هدف و کاربردی ندارد. این بخش، تنها قسمتی از الگوی MVC است که کاربر می‌تواند با آن تعامل داشته باشد. Controller را می‌توان به‌سادگی تحت‌عنوان گردآورنده اطلاعات (از کاربر) و ارسال‌کننده آنها به Model برای سازماندهی و ذخیره‌سازی درنظر گرفت و هیچ منطقی بجز آنچه که برای جمع‌آوری صحیح اطلاعات از کاربر لازم است، درون آن وجود ندارد. ضمناً Controller تنها با یک Model و ازطریق آن مدل، با یک View در ارتباط است و یک سیستم جریان داده یک‌طرفه ایجاد می‌کند. به‌خاطر سپردن این مسئله که Controller تنها وظایف خود را برای انجام‌دادن ازطریق عملیاتی که کاربر برروی View انجام می‌دهد دریافت‌کرده و سپس کار مناسب را درمقابل هر عمل کاربر انجام می‌دهد، اهمیت زیادی دارد. بیشترین اشتباهی که توسط توسعه‌دهندگان رخ می‌دهد، اشتباه‌گرفتن Controller بعنوان یک گذرگاه و درنهایت، اختصاص کاربردها و مسئولیت‌هایی به آن است که در اصل برعهده View می‌باشد (همان اشتباهی که موجب می‌شود تا View را در حد یک قالب نمایش، کوچک بشماریم). همچنین، یک اشتباه دیگر، اختصاص کاربردهایی به Controller است که مسئولیت پردازش اطلاعات دریافتی از Model و ارسال آنها به View را برعهده دارند (که در الگوی MVC این ارتباط، بین Model و View است).
