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

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

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

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

MVC کی تاریخ

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

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

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

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

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

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

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

یہاں ہمارے 2 مقاصد ہیں:

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

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

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

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

• آؤٹ پٹ اور آسانی سے صارف کو سسٹم کی معلومات ڈسپلے کریں۔
• صارف کا ڈیٹا اور کمانڈز درج کریں (ان کو سسٹم سے بات کریں)

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

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

اپنی ہاٹ چاکلیٹ پینے سے پہلے صرف ایک اور اہم بات پر بات کرنی ہے۔

اس بارے میں تھوڑا سا کہ منظر اور کنٹرولر ماڈل کے ساتھ کیسے تعامل کرتے ہیں۔

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

MVC: ہم کیا حاصل کرتے ہیں؟

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