حصہ 7۔ MVC (ماڈل ویو-کنٹرولر) پیٹرن کا تعارف

یہ مواد "انٹرپرائز ڈویلپمنٹ کا تعارف" سیریز کا حصہ ہے۔ پچھلے مضامین:

• نیٹ ورک کے بارے میں
• سافٹ ویئر فن تعمیر کے بارے میں
• HTTP/HTTPS پروٹوکول کے بارے میں ؛
• Maven کی بنیادی باتوں کے بارے میں
• servlets کے بارے میں (ہم ایک سادہ ویب ایپلیکیشن لکھ رہے ہیں) ؛
• سرولیٹ کنٹینرز کے بارے میں

اس مواد میں ہم آپ کو MVC جیسی چیز سے متعارف کرائیں گے۔ آئیے اس کے بارے میں بات کرتے ہیں کہ MVC کیا ہے، اس کی تخلیق کی تاریخ کو چھوئیں، MVC میں موجود اہم نظریات اور تصورات کو سمجھیں، مرحلہ وار غور کریں کہ کسی ایپلیکیشن کو ماڈل، ویو، کنٹرولر ماڈیولز میں کیسے توڑا جائے، اور اس میں ایک چھوٹی ویب ایپلیکیشن بھی لکھیں۔ Spring-Boot، اور Spring-MVC کو بطور مثال استعمال کرتے ہوئے، آئیے دیکھتے ہیں کہ جاوا کوڈ سے HTML صفحات پر ڈیٹا کیسے منتقل ہوتا ہے۔ اس مواد کو سمجھنے کے لیے، آپ کو ڈیزائن کے نمونوں، خاص طور پر آبزرور اور اگواڑے سے واقف ہونا ضروری ہے۔ HTTP درخواستوں اور جوابات سے واقف ہوں، html کی بنیادی باتوں کو سمجھیں، جانیں کہ جاوا میں تشریحات کیا ہیں۔ واپس بیٹھیں، چائے بنائیں، میٹھا، سلاد، مین کورس اور پہلا کورس تیار کریں۔ ہم شروع کرتے ہیں.

MVC کی تاریخ

MVC کے لیے خیالات Trygve Reenskaug نے 70 کی دہائی کے آخر میں زیروکس PARC میں کام کرتے ہوئے وضع کیے تھے۔ ان دنوں میں، کمپیوٹر کے ساتھ کام کرنا ایک تعلیمی ڈگری اور بڑی دستاویزات کے مسلسل مطالعہ کے بغیر کرنا ناممکن تھا۔ Reenskaug نے بہت مضبوط ڈویلپرز کے ایک گروپ کے ساتھ مل کر جو مسئلہ حل کیا وہ کمپیوٹر کے ساتھ اوسط صارف کے تعامل کو آسان بنانا تھا۔ ایسے اوزار بنانے کی ضرورت تھی جو ایک طرف تو انتہائی آسان اور قابل فہم ہوں اور دوسری طرف کمپیوٹر اور پیچیدہ ایپلی کیشنز کو منظم کرنا ممکن بنائیں۔ Reenskaug نے ایک ٹیم پر کام کیا جس نے "ہر عمر کے بچوں کے لیے" ایک پورٹیبل کمپیوٹر تیار کیا - Dynabook کے ساتھ ساتھ ایلن کی کی قیادت میں سمال ٹاک زبان۔ یہ تب اور وہیں تھا کہ ایک دوستانہ انٹرفیس کے تصورات مرتب کیے گئے تھے۔ Reenskaug کے اپنی ٹیم کے ساتھ کام نے IT فیلڈ کی ترقی کو بہت متاثر کیا۔ آئیے ایک دلچسپ حقیقت پیش کرتے ہیں جو براہ راست MVC سے متعلق نہیں ہے، لیکن ان پیش رفت کی اہمیت کو واضح کرتی ہے۔ 2007 میں، ایپل آئی فون کی پیشکش کے بعد، ایلن کی نے کہا: "جب میکنٹوش سامنے آیا، نیوز ویک نے پوچھا کہ میں اس کے بارے میں کیا سوچتا ہوں۔ میں نے کہا: یہ پہلا ذاتی کمپیوٹر ہے جو تنقید کے لائق ہے۔ پریزنٹیشن کے بعد اسٹیو جابز سامنے آئے اور پوچھا: کیا آئی فون تنقید کے قابل ہے؟ اور میں نے کہا، اسے پانچ بائی آٹھ انچ کرو اور تم دنیا کو فتح کر لو گے۔ تین سال بعد 27 جنوری 2010 کو ایپل نے 9.7 انچ کا آئی پیڈ متعارف کرایا۔ یعنی اسٹیو جابز نے تقریباً لفظی طور پر ایلن کی کے مشورے پر عمل کیا۔ Rennskaug جس پراجیکٹ پر کام کیا وہ 10 سال تک جاری رہا۔ اور اس کے تخلیق کاروں سے MVC کے بارے میں پہلی اشاعت ایک اور 10 سال بعد شائع ہوئی۔ سافٹ ویئر فن تعمیر پر متعدد کتابوں اور مضامین کے مصنف مارٹن فاؤلر نے ذکر کیا ہے کہ اس نے سمال ٹاک کے ورکنگ ورژن سے MVC سیکھا۔ چونکہ ایک طویل عرصے سے بنیادی ماخذ سے MVC کے بارے میں کوئی معلومات نہیں تھی، اسی طرح کئی دیگر وجوہات کی بناء پر، اس تصور کی مختلف تشریحات کی ایک بڑی تعداد سامنے آئی ہے۔ نتیجے کے طور پر، بہت سے لوگ MVC کو ڈیزائن اسکیم یا پیٹرن سمجھتے ہیں۔ کم عام طور پر، MVC کو ایک جامع پیٹرن یا کئی پیٹرن کا مجموعہ کہا جاتا ہے جو پیچیدہ ایپلی کیشنز کو لاگو کرنے کے لیے مل کر کام کرتے ہیں۔ لیکن درحقیقت، جیسا کہ پہلے کہا گیا ہے، MVC بنیادی طور پر آرکیٹیکچرل آئیڈیاز/اصولوں/طریقہ کاروں کا ایک مجموعہ ہے جسے مختلف نمونوں کا استعمال کرتے ہوئے مختلف طریقوں سے لاگو کیا جا سکتا ہے۔

MVC کیا ہے: بنیادی نظریات اور اصول

• VC ایک صارف انٹرفیس کے ساتھ پیچیدہ معلوماتی نظام کی تعمیر کے لیے تعمیراتی نظریات اور اصولوں کا ایک مجموعہ ہے۔
• MVC ایک مخفف ہے جس کا مطلب ماڈل-ویو-کنٹرولر ہے۔

اعلان دستبرداری: MVC ڈیزائن پیٹرن نہیں ہے۔ MVC ایک صارف انٹرفیس کے ساتھ پیچیدہ نظاموں کی تعمیر کے لیے مخصوص طور پر تعمیراتی نظریات اور اصولوں کا ایک مجموعہ ہے۔ لیکن سہولت کے لیے، تاکہ ہر بار دہرایا نہ جائے: "آرکیٹیکچرل آئیڈیاز کا ایک مجموعہ..."، ہم MVC کو پیٹرن کہیں گے۔ آئیے کچھ آسان کے ساتھ شروع کریں۔ Model-View-Controller کے الفاظ کے پیچھے کیا چھپا ہے؟ یوزر انٹرفیس کے ساتھ سسٹم تیار کرتے وقت، MVC پیٹرن کی پیروی کرتے ہوئے، آپ کو سسٹم کو تین اجزاء میں تقسیم کرنے کی ضرورت ہے۔ یہ، بدلے میں، ماڈیول یا اجزاء کہا جا سکتا ہے. کہو جو آپ چاہتے ہیں، لیکن تین سے تقسیم کریں۔ ہر جزو کا اپنا مقصد ہوگا۔ ماڈل۔ پہلا جزو/ماڈیول نام نہاد ماڈل ہے۔ اس میں درخواست کی تمام کاروباری منطق شامل ہے۔ دیکھیں۔ نظام کا دوسرا حصہ نظارہ ہے۔ یہ ماڈیول صارف کو ڈیٹا دکھانے کا ذمہ دار ہے۔ صارف جو کچھ بھی دیکھتا ہے وہ منظر سے تیار ہوتا ہے۔ کنٹرولر اس سلسلہ کی تیسری کڑی کنٹرولر ہے۔ یہ کوڈ کو اسٹور کرتا ہے جو صارف کے اعمال کی پروسیسنگ کے لیے ذمہ دار ہے (نظام میں صارف کی کسی بھی کارروائی کو کنٹرولر میں پروسیس کیا جاتا ہے)۔ ماڈل سسٹم کا سب سے آزاد حصہ ہے۔ اتنا آزاد کہ اسے ویو اور کنٹرولر ماڈیولز کے بارے میں کچھ نہیں معلوم ہونا چاہیے۔ ماڈل اتنا آزاد ہے کہ اس کے ڈویلپرز کو ویو اور کنٹرولر کے بارے میں عملی طور پر کچھ نہیں معلوم ہو سکتا ہے۔ ویو کا بنیادی مقصد ماڈل سے صارف دوست فارمیٹ میں معلومات فراہم کرنا ہے۔ ویو کی بنیادی حد یہ ہے کہ اسے کسی بھی طرح سے ماڈل کو تبدیل نہیں کرنا چاہئے۔ کنٹرولر کا بنیادی مقصد صارف کے اعمال پر کارروائی کرنا ہے۔ یہ کنٹرولر کے ذریعے ہے کہ صارف ماڈل میں تبدیلیاں کرتا ہے۔ زیادہ واضح طور پر، ماڈل میں محفوظ کردہ ڈیٹا میں۔ آئیے ایک بار پھر وہ خاکہ پیش کرتے ہیں جو آپ کو پہلے ہی لیکچر میں دکھایا گیا تھا: اس سب سے ہم ایک مکمل منطقی نتیجہ اخذ کر سکتے ہیں۔ ایک پیچیدہ نظام کو ماڈیولز میں تقسیم کرنے کی ضرورت ہے۔ آئیے مختصراً ان اقدامات کو بیان کرتے ہیں کہ اس طرح کی علیحدگی کیسے حاصل کی جائے۔

مرحلہ 1: ایپلیکیشن کی کاروباری منطق کو صارف کے انٹرفیس سے الگ کریں۔

MVC کا کلیدی خیال یہ ہے کہ صارف کے انٹرفیس کے ساتھ کسی بھی ایپلیکیشن کو، پہلے اندازے کے مطابق، 2 ماڈیولز میں تقسیم کیا جا سکتا ہے: ایک ماڈیول جو ایپلیکیشن کی کاروباری منطق کو نافذ کرنے کا ذمہ دار ہے، اور ایک صارف انٹرفیس۔ پہلا ماڈیول ایپلی کیشن کی اہم فعالیت کو نافذ کرے گا۔ یہ ماڈیول سسٹم کا بنیادی مرکز ہو گا، جس میں ایپلیکیشن ڈومین ماڈل کو لاگو کیا جاتا ہے۔ MVC تصور میں، یہ ماڈیول ہمارا حرف M ہو گا، یعنی ماڈل دوسرا ماڈیول پورے یوزر انٹرفیس کو نافذ کرے گا، بشمول صارف کو ڈیٹا کی نمائش اور ایپلی کیشن کے ساتھ صارف کے تعامل کی منطق۔ اس علیحدگی کا بنیادی مقصد اس بات کو یقینی بنانا ہے کہ نظام کی بنیادی (MVC اصطلاحات میں ماڈل) کو آزادانہ طور پر تیار اور جانچا جا سکے۔ اس طرح کی تقسیم کے بعد ایپلیکیشن کا فن تعمیر اس طرح نظر آئے گا:

مرحلہ 2۔ آبزرور پیٹرن کا استعمال کرتے ہوئے، ماڈل کی اور بھی زیادہ آزادی حاصل کریں، نیز یوزر انٹرفیس کی ہم آہنگی

یہاں ہم 2 مقاصد کا تعاقب کرتے ہیں:

1. ماڈل کی اور بھی زیادہ آزادی حاصل کریں۔
2. یوزر انٹرفیس کو سنکرونائز کریں۔

درج ذیل مثال سے آپ کو یہ سمجھنے میں مدد ملے گی کہ یوزر انٹرفیس کو سنکرونائز کرنے سے کیا مراد ہے۔ ہم کہتے ہیں کہ ہم فلم کا ٹکٹ آن لائن خریدتے ہیں اور تھیٹر میں دستیاب سیٹوں کی تعداد دیکھتے ہیں۔ کوئی اور ہماری طرح ایک ہی وقت میں فلم کا ٹکٹ خرید سکتا ہے۔ اگر یہ کوئی ہمارے سامنے ٹکٹ خریدتا ہے، تو ہم یہ دیکھنا چاہیں گے کہ ہمارے سیشن کے لیے دستیاب نشستوں کی تعداد کم ہوئی ہے۔ اب سوچتے ہیں کہ اس کو پروگرام کے اندر کیسے لاگو کیا جا سکتا ہے۔ آئیے فرض کریں کہ ہمارے پاس سسٹم کور (ہمارا ماڈل) اور ایک انٹرفیس ہے (وہ ویب صفحہ جس پر ہم خریداری کرتے ہیں)۔ سائٹ پر، 2 صارفین بیک وقت ایک سیٹ کا انتخاب کرتے ہیں۔ پہلے صارف نے ٹکٹ خریدا۔ دوسرے صارف کو یہ معلومات صفحہ پر ظاہر کرنے کی ضرورت ہے۔ یہ کیسے ہونا چاہیے؟ اگر ہم سسٹم کرنل سے انٹرفیس کو اپ ڈیٹ کرتے ہیں، تو ہمارا دانا، ہمارا ماڈل، انٹرفیس پر منحصر ہوگا۔ ماڈل کی تیاری اور جانچ کرتے وقت، آپ کو انٹرفیس کو اپ ڈیٹ کرنے کے مختلف طریقوں کو ذہن میں رکھنا ہوگا۔ اس کو حاصل کرنے کے لیے، آپ کو آبزرور پیٹرن کو لاگو کرنے کی ضرورت ہے۔ اس کی مدد سے، ماڈل تمام صارفین کو تبدیلیوں کے بارے میں اطلاعات بھیجتا ہے۔ انٹرفیس، اس طرح کے سبسکرائبر ہونے کے ناطے، ایک اطلاع اور اپ ڈیٹ حاصل کرے گا۔ آبزرور پیٹرن ماڈل کو، ایک طرف، انٹرفیس (دیکھنے اور کنٹرولر) کو مطلع کرنے کی اجازت دیتا ہے کہ اس میں تبدیلیاں واقع ہوئی ہیں، اور دوسری طرف، حقیقت میں ان کے بارے میں کچھ بھی "جاننا" نہیں ہے، اور اس طرح خود مختار رہتے ہیں۔ دوسری طرف، یہ صارف کے انٹرفیس کو مطابقت پذیر ہونے کی اجازت دے گا.

مرحلہ 3۔ انٹرفیس کو ویو اور کنٹرولر میں تقسیم کرنا

ہم ایپلیکیشن کو ماڈیولز میں تقسیم کرتے رہتے ہیں، لیکن درجہ بندی کی نچلی سطح پر۔ اس مرحلے میں، یوزر انٹرفیس (جسے مرحلہ 1 میں الگ ماڈیول میں الگ کیا گیا تھا) کو ایک ویو اور کنٹرولر میں تقسیم کیا گیا ہے۔ کسی منظر اور کنٹرولر کے درمیان سخت لکیر کھینچنا مشکل ہے۔ اگر ہم یہ کہتے ہیں کہ منظر وہی ہے جو صارف دیکھتا ہے، اور کنٹرولر وہ طریقہ کار ہے جس کے ذریعے صارف سسٹم کے ساتھ تعامل کرسکتا ہے، اس میں کچھ تضاد ہے۔ کنٹرولز، جیسے کہ ویب صفحہ پر بٹن یا فون اسکرین پر ورچوئل کی بورڈ، بنیادی طور پر کنٹرولر کا حصہ ہوتے ہیں۔ لیکن وہ صارف کے لیے بالکل اسی طرح نظر آتے ہیں جتنا کہ کسی بھی منظر کا حصہ۔ یہاں ہم فنکشنل ڈویژن کے بارے میں مزید بات کر رہے ہیں۔ صارف انٹرفیس کا بنیادی کام سسٹم کے ساتھ صارف کے تعامل کو یقینی بنانا ہے۔ اس کا مطلب ہے کہ انٹرفیس میں صرف 2 افعال ہیں:

• صارف کو سسٹم کے بارے میں معلومات کو ظاہر اور آسانی سے ظاہر کرنا؛
• سسٹم میں صارف کا ڈیٹا اور کمانڈ داخل کریں (ان کو سسٹم میں منتقل کریں)؛

یہ افعال طے کرتے ہیں کہ انٹرفیس کو ماڈیولز میں کیسے تقسیم کیا جانا چاہیے۔ نتیجے کے طور پر، سسٹم کا فن تعمیر اس طرح نظر آتا ہے: لہذا، ہمارے پاس ماڈل، ویو اور کنٹرولر نامی تین ماڈیولز کا اطلاق ہے۔ مختصر کرنے کے لئے:

1. MVC کے اصولوں پر عمل کرتے ہوئے، نظام کو ماڈیولز میں تقسیم کرنے کی ضرورت ہے۔
2. سب سے اہم اور آزاد ماڈیول ماڈل ہونا چاہیے۔
3. ماڈل سسٹم کا بنیادی حصہ ہے۔ آپ کو انٹرفیس سے آزادانہ طور پر اسے تیار کرنے اور جانچنے کی صلاحیت کی ضرورت ہے۔
4. ایسا کرنے کے لیے، نظام کی علیحدگی کے پہلے مرحلے پر، آپ کو اسے ایک ماڈل اور ایک انٹرفیس میں تقسیم کرنے کی ضرورت ہے۔
5. اگلا، آبزرور پیٹرن کا استعمال کرتے ہوئے، ہم ماڈل کو اس کی آزادی میں مضبوط بناتے ہیں اور یوزر انٹرفیس کی ہم آہنگی حاصل کرتے ہیں۔
6. تیسرا مرحلہ انٹرفیس کو کنٹرولر اور ویو میں تقسیم کرنا ہے۔
7. سسٹم میں صارف سے معلومات داخل کرنے کے لیے جو کچھ درکار ہے وہ کنٹرولر میں ہے۔
8. سسٹم سے صارف تک معلومات پہنچانے والی تمام چیزیں نظر میں ہیں۔

ابھی ایک اور اہم بات باقی ہے اور آپ کوکو پی سکتے ہیں۔

ویو اور کنٹرولر اور ماڈل کے درمیان تعلق کے بارے میں تھوڑا سا

جب صارف کنٹرولر کے ذریعے معلومات داخل کرتا ہے، تو وہ اس طرح ماڈل میں تبدیلیاں کرتا ہے۔ کم از کم صارف ماڈل ڈیٹا میں تبدیلیاں کرتا ہے۔ جب صارف انٹرفیس عناصر کے ذریعے معلومات حاصل کرتا ہے (ویو کے ذریعے)، صارف ماڈل ڈیٹا کے بارے میں معلومات حاصل کرتا ہے۔ یہ کیسے ہوتا ہے؟ دیکھیں اور کنٹرولر ماڈل کے ساتھ کیسے تعامل کرتے ہیں؟ آخرکار، یہ نہیں ہو سکتا کہ ویو کلاسز ڈیٹا کو پڑھنے/لکھنے کے لیے ماڈل کلاسز کے طریقوں کو براہ راست استعمال کریں، بصورت دیگر ماڈل کی آزادی کا کوئی سوال ہی پیدا نہیں ہو سکتا۔ ماڈل کلاسوں کے ایک مضبوطی سے جڑے ہوئے سیٹ کی نمائندگی کرتا ہے جس تک، اچھے طریقے سے، نہ تو ویو اور نہ ہی کنٹرولر کو رسائی حاصل ہونی چاہیے۔ ماڈل کو ویو اور کنٹرولر سے جوڑنے کے لیے، فیکیڈ ڈیزائن پیٹرن کو لاگو کرنا ضروری ہے۔ ماڈل کا اگواڑا ماڈل اور انٹرفیس کے درمیان بہت پرت ہو گا، جس کے ذریعے ویو ایک آسان فارمیٹ میں ڈیٹا حاصل کرتا ہے، اور کنٹرولر ضروری چہرے کے طریقوں کو کال کر کے ڈیٹا کو تبدیل کرتا ہے۔ منصوبہ بندی کے مطابق، آخر میں، سب کچھ اس طرح نظر آئے گا:

MVC: کیا فائدہ ہے؟

MVC اصولوں پر عمل کرنے کا بنیادی مقصد ایپلی کیشن کے کاروباری منطق (ماڈل) کے نفاذ کو اس کے تصور (نظر) سے الگ کرنا ہے۔ اس علیحدگی سے کوڈ کے دوبارہ استعمال میں اضافہ ہوگا۔ MVC استعمال کرنے کے فوائد ان صورتوں میں سب سے زیادہ واضح ہیں جہاں صارف کو مختلف شکلوں میں ایک ہی ڈیٹا فراہم کرنے کی ضرورت ہوتی ہے۔ مثال کے طور پر، ٹیبل، گراف یا چارٹ کی شکل میں (مختلف اقسام کا استعمال کرتے ہوئے)۔ ایک ہی وقت میں، خیالات کے نفاذ کو متاثر کیے بغیر، آپ صارف کے اعمال (بٹن پر کلک کرنا، ڈیٹا داخل کرنا) کے رد عمل کو تبدیل کر سکتے ہیں۔ اگر آپ MVC کے اصولوں پر عمل کرتے ہیں، تو آپ پروگراموں کی تحریر کو آسان بنا سکتے ہیں، کوڈ کی پڑھنے کی اہلیت کو بڑھا سکتے ہیں، اور مستقبل میں سسٹم کو وسعت دینے اور اسے برقرار رکھنے میں آسانی پیدا کر سکتے ہیں۔ "انٹرپرائز ڈویلپمنٹ کا تعارف" سیریز کے آخری مواد میں، ہم مثال کے طور پر Spring-MVC کا استعمال کرتے ہوئے MVC کے نفاذ کو دیکھیں گے۔ حصہ 8۔ بہار بوٹ میں ایک چھوٹی ایپلی کیشن لکھنا