پروجیکٹ منطق کا نفاذ

نفاذ کے نقطہ نظر کے فلسفے

آبشار کا نقطہ نظر

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

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

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

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

 کوئی بھی مسئلہ ترقیاتی ٹیم کے ذریعہ طے کیا جائے گا۔ جانچ اور تدارک کا عمل مکمل ہونے کے بعد، درخواست قبولیت کی جانچ کے لیے آخری صارف کے حوالے کر دی جاتی ہے۔ آخری صارف یہ دیکھنے کے لیے حتمی جانچ کرتا ہے کہ آیا درخواست ابتدائی تقاضوں کی تعمیل کرتی ہے۔ اگر منظور ہو جاتا ہے، تو وہ تیار شدہ مصنوعات کی منظوری دیتا ہے اور منصوبہ مکمل ہو جاتا ہے۔

آخری صارف یہ دیکھنے کے لیے حتمی جانچ کرتا ہے کہ آیا درخواست ابتدائی تقاضوں کی تعمیل کرتی ہے۔ اگر منظور ہو جاتا ہے، تو وہ تیار شدہ مصنوعات کی منظوری دیتا ہے اور منصوبہ مکمل ہو جاتا ہے۔ آخری صارف یہ دیکھنے کے لیے حتمی جانچ کرتا ہے کہ آیا درخواست ابتدائی تقاضوں کی تعمیل کرتی ہے۔ اگر منظور ہو جاتا ہے، تو وہ تیار شدہ مصنوعات کی منظوری دیتا ہے اور منصوبہ مکمل ہو جاتا ہے۔

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

آبشار کے نقطہ نظر کا فائدہ یہ ہے کہ ہر مرحلے کے لئے ذمہ دار ٹیم کی ذمہ داری زیادہ ہے. یہ واضح ہے کہ انہیں کیا ڈیلیور کرنے کی ضرورت ہے، انہیں کب ڈیلیور کرنے کی ضرورت ہے اور انہیں کس کو ڈیلیور کرنے کی ضرورت ہے۔ اکثر اوقات، ترقیاتی ٹیم کو صارف کے ساتھ بات چیت کرنے کی ضرورت نہیں ہوگی۔ کسی دوسرے ملک میں ترقی کو آؤٹ سورس کرتے وقت یہ بہت مفید ہو سکتا ہے۔

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

فرتیلی ترقی

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

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

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

بڑھتی ہوئی ترقی

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

فائدہ یہ ہے کہ رسمیں اپنی جگہ پر رہتی ہیں، لیکن تبدیلی کا انتظام آسان ہو جاتا ہے۔ ایک ایپلیکیشن کو متعدد بار جانچنے اور تعینات کرنے کی لاگت صرف ایک بار کرنے سے زیادہ ہوگی۔

پروگرام فلو کنٹرول

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

آرگنائزنگ کوڈ

پروگرام کے بہاؤ کو ڈیزائن کرنے کا پہلا قدم کوڈ کو منظم کرنا ہے، درخواست کی منصوبہ بندی، یا خاکہ بنانے میں مدد کے لیے قواعد کا ایک سیٹ قائم کرنا ہے۔ دیکھ بھال، ڈیبگنگ، اور بگ فکسنگ زیادہ آسانی سے ہو جائے گی کیونکہ کوڈ ایک منطقی مقام پر واقع ہے۔ بنیادی کام کرنے کے بعد، آپ اپنی درخواست کی منطق کو نافذ کرنے کے لیے ایک طریقہ منتخب کر سکتے ہیں۔

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

پروجیکٹ کی تخلیق

تہیں

پہلا قدم منطقی تہوں پر غور کرنا ہے۔ نوٹ کریں کہ پرتیں تہوں جیسی نہیں ہیں، اکثر الجھ جاتی ہیں یا ایک جیسی سمجھی جاتی ہیں۔

پرتیں بمقابلہ پرتیں۔

پرتیں آپ کے کوڈ میں حدود بنانے کے بارے میں ہیں۔ اوپری پرت میں نچلی پرتوں میں کوڈ کے حوالے ہو سکتے ہیں، لیکن کسی پرت میں کبھی بھی اعلیٰ پرت میں کوڈ کا حوالہ نہیں ہو سکتا۔ تہہ بندی متعدد کمپیوٹرز میں تہوں کی جسمانی تقسیم سے متعلق ہے۔ مثال کے طور پر، تین درجے کی ایپلی کیشن میں، یوزر انٹرفیس کو ڈیسک ٹاپ کمپیوٹر پر چلانے کے لیے ڈیزائن کیا گیا ہے، ایپلیکیشن لاجک کو ایپلیکیشن سرور پر چلانے کے لیے ڈیزائن کیا گیا ہے، اور ڈیٹا بیس ڈیٹا بیس سرور پر چلتا ہے۔ ہر پرت متعدد تہوں پر مشتمل ہو سکتی ہے۔

شکل 8-1: بنیادی تین درجے کی تنظیم

تہوں سے مراد تجرید کی سطح ہے۔ تصویر 8-1 میں دکھائی گئی پرتیں زیادہ تر ایپلی کیشنز کے لیے درست ہیں۔ ان سطحوں کو تین اہم تہوں کے نام سے بھی جانا جاتا ہے اور ان کے کئی دوسرے نام بھی ہو سکتے ہیں۔ ایک اصول کے طور پر، پریزنٹیشن پرت میں کوڈ ایپلی کیشن کی منطقی پرت میں خدمات کو کال کر سکتا ہے، لیکن ایپلیکیشن منطقی پرت کو پریزنٹیشن پرت میں طریقہ کو کال نہیں کرنا چاہیے۔ پریزنٹیشن پرت کو کبھی بھی ڈیٹا تک رسائی کی پرت کو براہ راست کال نہیں کرنا چاہئے، کیونکہ یہ ایپلیکیشن لاجک پرت کے ذریعہ لاگو کردہ ذمہ داریوں کو نظرانداز کرے گا۔ ڈیٹا تک رسائی کی پرت کو کبھی بھی ایپلیکیشن لاجک پرت کو کال نہیں کرنا چاہئے۔

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

جسمانی تہوں

انٹرپرائز ایپلی کیشن میں، آپ کو ایک ہی منطق کے لیے متعدد کلائنٹس کی توقع کرنی چاہیے۔ درحقیقت، جو چیز کسی ایپلیکیشن کو انٹرپرائز ایپلی کیشن بناتی ہے وہ یہ ہے کہ اسے تین پرتوں میں تعینات کیا جائے گا: کلائنٹ، ایپلیکیشن سرور اور ڈیٹا بیس سرور۔ آپ کی کمپنی کے سیلز ڈیپارٹمنٹ کی طرف سے تیار کردہ Microsoft Office Access ایپلیکیشن، اگرچہ سیلز ڈیپارٹمنٹ کے لیے بہت اہم ہے، لیکن انٹرپرائز ایپلی کیشن تشکیل نہیں دیتی۔

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

پرتوں میں پیٹرن شامل کرنا

تین بنیادی پرتیں ایک اعلیٰ سطحی جائزہ فراہم کرتی ہیں۔ آئیے ایک مضبوط انٹرپرائز آرکیٹیکچر بنانے کے لیے کچھ ساختی نمونے شامل کریں۔ نتیجہ تصویر 8-2 میں دکھایا گیا ہے۔

ایپلی کیشن منطق کی پرت پر توجہ دیں۔ شکل 8-2 سے پتہ چلتا ہے کہ درخواست کی منطق تک رسائی فیکیڈ پیٹرن کا استعمال کر رہی ہے۔ اگواڑا ایک ایسی چیز ہے جو کوڈ کے بڑے جسم کو ایک آسان انٹرفیس فراہم کرتی ہے، جیسے کہ کلاس لائبریری۔ ایک اگواڑا لائبریری کے اندرونی کاموں پر بیرونی کوڈ کے انحصار کو کم کر سکتا ہے کیونکہ زیادہ تر کوڈ اگواڑا استعمال کرتا ہے، اس طرح سسٹم کی ترقی میں زیادہ لچک پیدا ہوتی ہے۔ ایسا کرنے کے لیے، اگواڑا باریک دانے دار اشیاء کے مجموعے کو ایک موٹے دانے والا انٹرفیس فراہم کرے گا۔

فیصلے کا بہاؤ

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

آپ کی خدمات کو منظم کرنے کے دو طریقے ہیں:

• عمل پر مبنی
• ریاست پر مبنی

عمل پر مبنی نقطہ نظر

صارف کے اعمال کی بنیاد پر خدمات کو ترتیب دے کر، آپ خدمات کی پیشکش کر کے ایپلیکیشن منطق کو لاگو کر رہے ہیں، جن میں سے ہر ایک پریزنٹیشن لیئر سے مخصوص درخواست کو ہینڈل کرتا ہے۔ اسے ٹرانزیکشن اسکرپٹ پیٹرن کے نام سے بھی جانا جاتا ہے۔ یہ نقطہ نظر مقبول ہے کیونکہ یہ آسان ہے اور بہت قدرتی محسوس ہوتا ہے. اس نقطہ نظر کی پیروی کرنے والے طریقوں کی مثالیں BookStoreService.AddNewOrder(Order order) اور BookStoreService.CancelOrder(int orderId) ہیں۔

عمل کو انجام دینے کے لیے درکار منطق کو طریقہ کار کے اندر بہت ترتیب وار لاگو کیا جاتا ہے، جس سے یہ بہت پڑھنے کے قابل ہو جاتا ہے لیکن کوڈ کو دوبارہ استعمال کرنا زیادہ مشکل ہوتا ہے۔ اضافی ڈیزائن پیٹرن کا استعمال، جیسے ٹیبل ماڈیول پیٹرن، دوبارہ استعمال کی صلاحیت کو بڑھانے میں مدد کر سکتا ہے۔

ریاست پر مبنی نقطہ نظر

درخواست کے فیصلے کے بہاؤ کو بہت زیادہ ریاست پر مبنی انداز میں نافذ کرنا بھی ممکن ہے۔ ایپلیکیشن سرور کی طرف سے پیش کردہ خدمات فطرت میں زیادہ عام ہیں، مثال کے طور پر، BookStoreService.SaveOrder(Order آرڈر)۔ یہ طریقہ آرڈر کی صورتحال کو دیکھے گا اور فیصلہ کرے گا کہ آیا نیا آرڈر شامل کرنا ہے یا موجودہ آرڈر کو منسوخ کرنا ہے۔

ڈیٹا سٹرکچر پروجیکٹس

اپنے ڈیٹا ڈھانچے کو ڈیزائن کرتے وقت آپ کو کئی انتخاب کرنے چاہئیں۔ پہلا انتخاب ڈیٹا ذخیرہ کرنے کا طریقہ کار ہے، دوسرا ڈیٹا کا مطلوبہ استعمال ہے، اور تیسرا ورژن کی ضروریات ہیں۔ ڈیٹا ڈھانچے کے ڈیزائن کو دیکھنے کے تین طریقے ہیں:

• خدمات پیش کرتے ہیں ڈیٹا؛ ڈیٹا رشتہ دار ڈیٹا بیس کا عکس ہے۔
• ڈیٹا کو اشیاء کے ساتھ میپ کیا جانا چاہیے اور خدمات اشیاء تک رسائی فراہم کرتی ہیں۔
• خدمات کے ذریعہ پیش کردہ ڈیٹا اسکیما پر مبنی ہونا چاہئے۔

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

ڈیٹا اسٹوریج انجن کا انتخاب

اپنی ایپلیکیشن کو ڈیزائن کرتے وقت، آپ کو بلاشبہ کسی قسم کے ڈیٹا اسٹوریج کو ڈیزائن کرنا پڑے گا۔ درج ذیل اسٹورز اور ڈیٹا اسٹوریج کی شکلیں دستیاب ہیں:

• ریکارڈ
• app.config فائل
• XML فائلیں۔
• سادہ ٹیکسٹ فائلیں
• ڈیٹا بیس
• پیغام کی قطار

ہر اسٹور کی اپنی منفرد خصوصیات ہیں اور اسے مخصوص ضروریات کے مطابق بنایا جا سکتا ہے۔

ڈیٹا کے بہاؤ کو ڈیزائن کرنا

ADO.NET کا استعمال کرتے ہوئے ڈیٹا کا بہاؤ

ایپلیکیشن لاجک لیئر میں ڈیٹا سینٹرک سروسز کو لاگو کرتے وقت، آپ ADO.NET کا استعمال کرتے ہوئے اپنے ڈیٹا فلو کو ڈیزائن کریں گے۔ .NET فریم ورک کلاس لائبریری منظم کوڈ میں ڈیٹا کی ہیرا پھیری کے لیے ایک وسیع ایپلی کیشن پروگرامنگ انٹرفیس (API) فراہم کرتی ہے۔ ADO.NET کے طور پر حوالہ دیا گیا، API کو System.Data نام کی جگہ میں پایا جا سکتا ہے۔ میڈیا اور ڈیٹا اسٹورز کی مکمل علیحدگی ADO.NET کی ایک اہم ڈیزائن خصوصیت ہے۔ DataSet، DataTable اور DataRow جیسی کلاسز کو ڈیٹا اسٹور کرنے کے لیے ڈیزائن کیا گیا ہے، لیکن ان میں ڈیٹا کہاں سے آیا اس کا کوئی علم نہیں رکھتے۔ انہیں ڈیٹا سورس ایگنوسٹک سمجھا جاتا ہے۔ کلاسوں کا ایک الگ سیٹ، جیسے کہ SqlConnection، SqlDataAdapter، اور SqlCommand، ڈیٹا سورس سے منسلک ہونے، ڈیٹا کو بازیافت کرنے، اور DataSet، DataTable، اور DataRow کو آباد کرنے کا خیال رکھتا ہے۔ یہ کلاسز ذیلی نام کی جگہوں میں واقع ہیں جیسے System.Data.Sql، System.Data.OleDB، System.Data.Oracle، وغیرہ۔ اس بات پر منحصر ہے کہ آپ کس ڈیٹا سورس سے منسلک ہونا چاہتے ہیں، آپ صحیح نام کی جگہ میں کلاسز استعمال کر سکتے ہیں، اور آپ جو پروڈکٹ استعمال کر رہے ہیں اس کے دائرہ کار پر منحصر ہے، آپ دیکھیں گے کہ یہ کلاسیں کم و بیش فعالیت پیش کرتی ہیں۔

چونکہ ڈیٹا سیٹ ڈیٹا سورس سے منسلک نہیں ہے، اس لیے اسے کسی ایپلیکیشن میں ڈیٹا کے بہاؤ کو منظم کرنے کے لیے کافی کامیابی سے استعمال کیا جا سکتا ہے۔ شکل 8-5 ایسا کرتے وقت ڈیٹا کے بہاؤ کو ظاہر کرتی ہے۔

آئیے اس پروجیکٹ پر ایک نظر ڈالیں اور تصور کریں کہ کسی نے آپ کی کتابوں کی دکان میں لاگ ان کیا اور تین کتابوں کا آرڈر دیا۔ پریزنٹیشن پرت نے شاپنگ کارٹ کی حالت کو منظم کیا۔ کسٹمر آرڈر دینے کے لیے تیار ہے اور اس نے تمام ضروری ڈیٹا فراہم کر دیا ہے۔ وہ آرڈر بھیجنے کا انتخاب کرتا ہے۔ ویب صفحہ تمام ڈیٹا کو ڈیٹا سیٹ میں تبدیل کرتا ہے جس میں دو ڈیٹا ٹیبلز ہوتے ہیں، ایک آرڈر کے لیے اور ایک آرڈر کے لیے۔ درخواست کے لیے ڈیٹا رو داخل کرتا ہے۔ اور آرڈر لائنوں کے لیے تین DataRows داخل کرتا ہے۔ ویب صفحہ اس ڈیٹا کو ایک بار پھر صارف کو دکھاتا ہے، ڈیٹا سیٹ کے خلاف ڈیٹا بائنڈنگ کو کنٹرول کرتا ہے، اور پوچھتا ہے کیا آپ کو یقین ہے؟ صارف درخواست کی تصدیق کرتا ہے اور اسے درخواست کی منطقی پرت میں جمع کر دیا جاتا ہے۔ ایپلیکیشن لاجک لیئر ڈیٹا سیٹ کو چیک کرتی ہے کہ آیا تمام مطلوبہ فیلڈز کی قدر ہے اور یہ دیکھنے کے لیے چیک کرتی ہے کہ آیا صارف کے پاس US$ 1,000 سے زیادہ ہے۔ 00 بقایا بلوں پر۔ اگر سب کچھ ٹھیک ہے تو، ڈیٹا سیٹ کو ڈیٹا تک رسائی کی پرت میں منتقل کیا جاتا ہے، جو ڈیٹا بیس سے منسلک ہوتا ہے اور ڈیٹا سیٹ کی معلومات کی بنیاد پر اندراج کی ہدایات تیار کرتا ہے۔

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

آبجیکٹ ریلیشنل میپنگ کا استعمال کرتے ہوئے ڈیٹا فلو

ADO.NET کا استعمال کرتے ہوئے ڈیٹا کا بہاؤ ڈیٹا کے بہاؤ کو منظم کرنے کے لیے ایک بہت ہی ڈیٹا سینٹرک طریقہ ہے۔ ڈیٹا اور منطق مجرد ہیں۔ سپیکٹرم کا دوسرا رخ زیادہ آبجیکٹ پر مبنی نقطہ نظر اختیار کر رہا ہے۔ یہاں، گروپ ڈیٹا اور رویے کے لیے کلاسز بنائی جاتی ہیں۔ مقصد ان کلاسوں کی وضاحت کرنا ہے جو کاروباری ڈومین میں پائے جانے والے ڈیٹا اور رویے کی نقل کرتے ہیں جس کے لیے ایپلیکیشن بنائی گئی تھی۔ نتیجہ اکثر کاروباری چیز کے طور پر کہا جاتا ہے. کاروباری اشیاء کا مجموعہ جو ایپلی کیشن بناتا ہے اسے ڈومین ماڈل کہا جاتا ہے۔ کچھ ڈویلپرز کا دعویٰ ہے کہ زیادہ پیچیدہ منطق کو ڈیزائن کرنے کے لیے ایک بھرپور ڈومین ماڈل بہتر ہے۔ ایسے بیان کو ثابت کرنا یا غلط ثابت کرنا مشکل ہے۔ بس جان لیں کہ آپ کے پاس ایک انتخاب ہے اور اسے بنانا آپ پر منحصر ہے۔

شکل 8-6 اعداد و شمار کے بہاؤ کو شکل 8-5 کی طرح دکھاتا ہے، سوائے اس کے کہ اب آپ نے آبجیکٹ-ریلیشنل میپنگ لیئر کو شامل کیا ہے اور ڈیٹا سیٹ آبجیکٹ کو مختلف ڈیٹا کیریئرز سے بدل دیا ہے۔

اب پہلے کی طرح قدم بہ قدم کریں۔ تصور کریں کہ کسی نے آپ کی کتابوں کی دکان میں لاگ ان کیا اور تین کتابوں کا آرڈر دیا۔ پریزنٹیشن پرت نے شاپنگ کارٹ کی حالت کو منظم کیا۔ کسٹمر آرڈر دینے کے لیے تیار ہے اور اس نے تمام ضروری ڈیٹا فراہم کر دیا ہے۔ وہ آرڈر بھیجنے کا انتخاب کرتا ہے۔ ویب صفحہ تمام ڈیٹا کو ڈی ٹی او میں تبدیل کرتا ہے، ایک آرڈر کے لیے ڈیٹا رکھتا ہے اور تین آرڈر لائنوں کے ساتھ، ضرورت کے مطابق اشیاء بناتا ہے۔ ویب صفحہ اس ڈیٹا کو صارف کو ایک بار پھر دکھاتا ہے، ASP.NET 2.0 میں ObjectDataSource کا استعمال کرتے ہوئے DTO کے خلاف ڈیٹا بائنڈنگ کنٹرول، اور پوچھتا ہے کیا آپ کو یقین ہے؟ صارف انتخاب کی تصدیق کرتا ہے اور ڈی ٹی او کو درخواست کی منطقی پرت میں جمع کرایا جاتا ہے۔ ایپلیکیشن لاجک لیئر ڈی ٹی او کو تین آرڈر لائن اشیاء پر مشتمل پراپرٹی کے ساتھ آرڈر کی قسم کے کاروباری آبجیکٹ میں تبدیل کرتی ہے۔ آرڈر کا طریقہ۔ Validate() کو آرڈر کی توثیق کرنے اور یہ چیک کرنے کے لیے کہا جاتا ہے کہ آیا تمام لازمی فیلڈز کی ایک قدر ہے، اور یہ شناخت کرنے کے لیے چیک کیا جاتا ہے کہ آیا صارف کے پاس بقایا رسیدوں میں R$ 1,000.00 سے زیادہ ہے۔ ایسا کرنے کے لیے، آرڈر Order.Customer.GetOutstandingBills() کو کال کرے گا۔ اگر سب کچھ ٹھیک ہے تو Order.Save() طریقہ کہا جاتا ہے۔ آرڈر آبجیکٹ ریلیشنل میپنگ لیئر کو جمع کرائے گا، جہاں ڈیٹا سیٹ میں ڈیٹا ٹیبل پر آرڈر اور آرڈر لائنز کو میپ کیا جاتا ہے، اور ڈیٹا سیٹ کو ڈیٹا تک رسائی کی پرت میں منتقل کیا جاتا ہے، جو ڈیٹا بیس سے منسلک ہوتا ہے اور معلومات سے اندراج کی ہدایات تیار کرتا ہے۔ ڈیٹا سیٹ بے شک، بہت سے طریقے ہیں جن میں آبجیکٹ سے متعلق میپنگ ہو سکتی ہے، لیکن ان سب میں ڈیٹا سیٹ میں تبدیلی شامل نہیں ہوگی۔ کچھ براہ راست داخل کرنے کے بیانات تخلیق کریں گے، لیکن پھر بھی اس بیان کو انجام دینے کے لیے ڈیٹا تک رسائی کی پرت کا استعمال کریں گے۔

جیسا کہ آپ دیکھ سکتے ہیں، کچھ تبدیلیاں ہوتی ہیں۔ DTOs کا استعمال ضروری ہے کیونکہ ایک کاروباری چیز رویے کو نافذ کرتی ہے اور رویے میں تبدیلی ہوتی ہے۔ پریزنٹیشن لیئر پر ان تبدیلیوں کے اثرات کو کم کرنے کے لیے، آپ کو ڈیٹا کو بزنس آبجیکٹ سے باہر اور ڈیٹا ٹرانسفر آبجیکٹ میں تبدیل کرنے کی ضرورت ہے۔ جاوا میں، ڈیٹا ٹرانسفر آبجیکٹ کو عام طور پر ویلیو آبجیکٹ کہا جاتا ہے۔

کاروباری اشیاء کے ساتھ کام کرنے کا ایک بڑا فائدہ یہ ہے کہ یہ واقعی آپ کے کوڈ کو منظم کرنے میں مدد کرتا ہے۔ اگر آپ پیچیدہ منطق کے ایک ٹکڑے پر نظر ڈالتے ہیں، تو یہ عام طور پر بہت پڑھنے کے قابل ہوتا ہے کیونکہ وہاں پلمبنگ کوڈ بہت کم ہوتا ہے۔ منفی پہلو یہ ہے کہ زیادہ تر ڈیٹا اسٹورز اب بھی رشتہ دار ہیں اور کاروباری اشیاء کو رشتہ دار ڈیٹا سے نقشہ بنانا کافی پیچیدہ ہوسکتا ہے۔

اسکیما پر مبنی خدمات

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

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