نمط وعرض ومتحكم

(نموذج بيانات - عرض مرئي - متحكّم) ‍(الإنجليزية: MVC إم في سي نموذج بيانات - عرض مرئي - متحكم) هو أحد أشهر أنماط المعماريات البرمجيّة وأكثرها شيوعًا بين تلك التي تُستخدم لتطوير برامج ذات واجهة مستخدم رسوميّة (عرض مرئي). تتمثّل هذه المعمارية بتقسيم البرنامج إلى ثلاث وحدات وظيفية رئيسية مستقلّة بأدوارها عن بعضها ولكنها مرتبطة ومتصلة تفاعليّاً فيما بينها. تهدف هذه المعماريّة إلى فصل طريقة تمثيل نماذج البيانات, أي دورة حياتها, والعمليات المنطقية المطلوبة التي تجري عليها داخل البرمجيّة عن طريقة عرض الشكل النهائي لهذه البيانات للمستخدم.

وصف لمكونات (نموذج بيانات - عرض مرئي - متحكّم)

نبذة تاريخية

ابتكر ترايغف رينسكاوغ هذا النمط المعماري خلال عمله على مشروع ابتكار وتطوير لغة البرمجة سمول توك-79 بصفته عالم مساعد في شركة مركز الأبحاث زيروز بالو ألتو في أواخر عام 1970. كان يهدف ترايغف بهذا النمط لبناء البرامج بالشكل الذي يستطيع فيه المستخدمون التفاعل مع البيانات مهما كانت ضخمة أو معقّدة. النسخة الأوليّة من هذه المعمارية كانت تحتوي على أربعة أجزاء رئيسيّة: (نموذج - عرض مرئي - شيء - معدِّل). ولكن وبعد التباحث مع المطوّرين العاملين على مشروع سمول توك إجتمعوا على أن يقتصر النمط على ثلاثة أجزاء فقط (نموذج - عرض - متحكّم) بدلاً من الأربعة السابقة.

في النسخة التالية من اللّغة (سمول توك-80) طُوِّرت المعمارية فأصبح العرض فيها أكثر تجريديّة والمتحكّم كذلك متمثّلاً بفئات برمجيّة وفئات فرعيّة أخرى تمثّل عناصر الواجهة الرسوميّة الفرعيّة. وبهذا الشكل يكون العرض المرئي أداة لعرض البيانات للمستخدم والمتحكم أداة للتفاعل معها. أيضًا فإنّ النموذج مرتبط بالعرض المرئي متمثّلاً بكائن عن فئة برمجيّة ويترك شكل وبنية هذا الكائن للمطوّر. كما أنّ هذه النسخة من اللّغة احتوت على أداة عرض في بيئة التطوير خاصَّتها تفيد المطوّرين في تصفّح شكل وبناء النموذج والعرض المرئي والمتحكّم جنبًا إلى جنب.

النموذج المعماري تطوّر بشكل متتابع فيما بعد واشتقّت عنه نماذج معماريّة أخرى ومنها: (نموذج بيانات - عرض مرئي - متحكّم, هرمي), (نموذج بيانات - عرض مرئي - محوّل), (نموذج بيانات - عرض مرئي - مزوّد), (نموذج بيانات - عرض مرئي - نموذج عرضي وسيط).

فيما بعد ازدادت تطبيقات الشبكة العالميّة التي تتبنى هذه المعماريّة في بنائها وتطويرها وكان ذلك بشكل خاص بعد إطلاق شركة نيكست لإطار العمل البرمجي ويب أوبجيكتز والذي كان قد تمت كتابته في بادئ الأمر بلغة أوبجيكتف-سي والذي كان مقتبس بشكل كبير من إطار العمل سمول توك وذلك عام 1996. لاحقاً, أصبحت المعماريّة أكثر شيوعاً بين المطوّرين الذين يستخدمون لغة جافا وذلك بعد أن تم توجيه تطوير إطار العمل ويب أوبجيكتز ليكون بلغة جافا. زاد الربط بين هذا النموذج المعماري ولغة جافا وذلك بعد إطلاق عدة إطارات عمل برمجيّة جديدة بلغة جافا وبخاصّة سبرينغ والذي أطلق في أكتوبر من العام 2002.

في العام 2003 قام المطور مارتين فولير بنشر كتاب أنماط معمارية تطبيقات المشاريع "Patterns of Enterprise Application Architecture" والذي قدم فيه نمط (نموذج - عرض - متحكّم) ويشرح كيفيّة عمل هذا النمط حيث يستقبل راصد للمدخلات الطلبات ومن ثمّ يرسلها إلى نموذج متمثّل بكائن برمجي ويعيد إرسالها إلى واجهة العرض المرئي الخاص بهذه البيانات. منهجية هذا النمط قريبة من تلك التي المتبعة في إطار العمل روبي أون ريلز (أغسطس 2004). أيضاً إطار العمل جانغو (جوليو 2005) والذي طور باستخدام لغة بايثن فإنّ نمط معماريّته أيضاً مشابهة (نموذج - قالب - عرض) حيث أنّ العرض هنا أشبه بالبديل عن المتحكّم فهو المسؤول عن جلب البيانات المطلوبة من النموذج ثمّ يقوم بتمريرها إلى القالب ليعرضها. كلى الإطارين ظهرا بشكل قوي ومحكم في بنائهما ممّا زاد في شعبيّة وانتشار هذا النمط المعماري وامتداده خارج  بيئة التطوير السابقة التي كان فيها لمدّة طويلة.

مكونات النمط المعماري

النموذج البياني

هو الوحدة المسؤولة عن تمثيل البيانات على شكل نموذج برمجي (كائن برمجي أو مصفوفة) داخل البرنامج وبشكل مستقل عن وحدة العرض المرئي مما يتيح حريّة أكبر في التعامل مع البيانات وإجراء العمليات البرمجيّة المطلوبة عليها.

العرض المرئي

الوحدة المسؤولة عن عرض البيانات للمستخدم عن طريق واجهة رسوميّة كجداول عرض البيانات أو مخطط بياني.

المتحكّم

الوحدة المسؤولة عن ربط الوحدتين الأخريين وفيها يتم الوصول إلى البيانات المناسبة ومعالجة الطلبات والأوامر والتي عادة تكون من قبل المستخدم ومن ثمّ تزويد العرض بهذه البيانات.

إن نمط المعماريّة (نموذج - عرض - متحكّم) في البداية طوّر للبرامج المكتبيّة ولكنه استخدم فيما بعد لتطوير برامج الشبكة العالمية وقد كان له نجاح وانتشار كبير بذلك. إن هذا النمط يقدّم الحلول والتنسيق الملائم لهذه المكونات ليحلّ المشكلة الجوهريّة في الأمر في التنظيم والفصل الوظيفي لمكونات البرنامج وبذلك فهو يمثّل فقط الشكل العام وقد يختلف في تفاصيله الأخرى بين نسخه بالشكل الذي يتوافق فيه مع مكونات البرنامج الأخرى.