جمعه, ۲۳ آذر, ۱۴۰۳ / 13 December, 2024
مجله ویستا

استراتژی دستیابی به داده ها در وب


استراتژی دستیابی به داده ها در وب
در زمان طراحی و پیاده سازی یک برنامه تحت وب و بمنظور دستیابی به داده ها ، چالش های متعددی وجود دارد: نحوه ارتباط با یک منبع داده ، نحوه ذخیره سازی داده ها در زمان رفت و آمد صفحات بین سرویس گیرنده و سرویس دهنده ، محل ذخیره سازی داده ها در صورت تاکید بر ذخیره سازی داده ها و ... . نحوه برخورد با چالش های فوق و انتخاب راهکارهای متاسب ، در طراحی و پیاده سازی یک برنامه تحت وب تاثیرات خود را بدنبال داشته و می تواند در نحوه اجراء و کارائی برنامه ، پیامدهای مستقیمی را داشته باشد.
برای دستیابی به داده ها یک استراتژی ثابت و منفرد که در تمامی حالات پاسخگو باشد ،وجود نداشته و با انتخاب هر رویکرد می بایست پذیرای نکات مثبت و منفی آن نیز بود. در ادامه به بررسی اصول اولیه در طراحی صفحات فرم های وب بمنظور دستیابی به داده ها خواهیم پرداخت .
●DataSet or Direct Access and Data Reader
یکی از اولین مواردیکه می بایست به آن پاسخ داد این مطلب است که : " آیا می خواهیم رکوردها را بکمک یک Dataset استفاده نمود و یا قصد دستیابی به بانک اطلاعاتی را مستقیما" داشته و بکمک یک Data Reader از رکوردها استفاده نمائیم؟" برای انجام برخی عملیات نظیر ایجاد و ویرایش ساختار بانک اطلاعاتی نمی توان از یک Dataset استفاده نمود. مثلا" اگر بخواهیم ، ایجاد یک جدول جدید را از طریق برنامه انجام دهیم ،نمی توان از Dataset استفاده نمود. در حالت کلی برای دستیابی به داده ها می بایست بین استفاده از یک Dataset و یا کار مستقیم با بانک اطلاعاتی از طریق بخدمت گرفتن دستورات مربوطه یکی و یا هر دو را با توجه به شرایط حاکم بر یک برنامه انتخاب نمود. هر یک از رویکردهای فوق، دارای مزایا و معایبی می باشند. مثلا" Dataset جهت کار با جداول رابطه ای و کار با داده های مستقر شده در چندین جدول مناسبت تر بنظر می آیند. در مقابل استفاده از یک Data Reader دارای کارائی بیشتر مخصوصا" ازبعد استفاده از حافظه بوده که باعث حذف مراحل اضافی برای تکمیل و استقرار داده ها در یک DataSet خواهد شد. در این حالت امکان اعمال کنترل بیشتری بر روی داده ها از طریق عبارات و یا Stored Procedures ها نیز وجود خواهد داشت .
● DataSet and Data commands in web form pages
زمانیکه با صفحات فرم های وب کار می شود ، فاکتورهای دیگری نیز جهت انتخاب DataSet و یا Data Reader وجود خواهد داشت . یکی از این فاکتورها " چرخه حیات یک صفحه وب " است . صفحات فرم های وب ، مقداردهی اولیه ، پردازش و در نهایت حذف خواهند شد( به ازای هر رفت و آمد بین سرویس دهنده و سرویس گیرنده ) . در صورتیکه بخواهیم داده ها را بسادگی بر روی صفحه نمایش دهیم ، می توان یک Dataset را ایجاد و آن را از داده های مورد نظر تکمیل و در نهایت آن را به یک کنترل Bind نمود. عملیات فوق مستلزم overhead غیر ضروری است ، چون بلافاصله Dataset از بین خواهد رفت .در برخی موارد مناسبت تر است که از Data Reader بمنظور بازیابی داده ها استفاده و با Bind نمودن کنترل به آن در زمان اجراء، زمینه استفاده از داده ها را فراهم نمود. در حالت کلی می توان از دستورات مربوط جهت اجرای عبارات SQL و یا Stored Procedurdes استفاده کرد. مثلا" جهت نمایش داده ها در یک دستور DataList می توان یک عبارت SQL را اجراء و در ادامه کنترل مربوطه را به یک Data reader نسبت داد. در این زمینه برخی حالات خاص نیز وجود دارد که به آنها اشاره می گردد:
▪ کار با جداول رابطه ای . Dataset امکان پشتیبانی چندین جدول رابطه ای و حمایت از ارتباطات مربوطه را فراهم می نماید.کار با رکوردهای رابطه ای در یک Dataset بمراتب راحت تر از خواندن رکوردها بصورت مستقل و بکمک اجرای دستوراتی در رابطه با یک بانک اطلاعاتی است.
▪ مبادله داده بین سایر پردازش ها . در صورتیکه صفحات فرم های وب داده های خود را از سایر عناصر اخذ نمایند ،( نظیر سرویس های وب Xml) می بایست از یک Dataset جهت نگهداری یک نسخه از داده ها استفاده نمود.Dataset بصورت خودکار Xml های استفاده شده بین عناصر متفاوت در دات نت را خوانده و یا در آنها اطلاعاتی را خواهد نوشت.
▪ کار با یک مجموعه ثابت از رکوردها . در صورتیکه به مجموعه ای از رکوردها مکررا" نیاز باشد ،( مثلا" عملیات paging در یک grid) شایسته است که رکوردهای مورد نظر را در یک Dataset قرار داد.
یکی از مزایای عمده Dataset ، برنامه نویسی ساده تر آن نسبت به استفاده مستقیم از دستورات است .
●Save Dataset or Recreate each time
در صورت استفاده از یک DataSet ، تصمیم بعدی در رابطه با این موضوع خواهد بود که " آیا پس از هر رفت و آمد بین سرویس دهنده و سرویس گیرنده ، می بایست مجددا" Dataset را ایجاد نمود؟ در رابطه با مسئله فوق دو رویکرد وجود دارد :
▪ هر زمان که صفحه پردازش می گردد ،یک نمونه از Dataset ایجاد و مقدار دهی شود، .پس از اتمام پردازش صفحه و ارسال آن برای مرورگر ،Dataset حذف خواهد شد.
▪ ایجاد و تکمیل Dataset یک بار انجام شده ( اولین باری که صفحه اجراء می گردد) و درادامه Dataset را با یک روش ذخیره و در نهایت امکان بازیابی و استفاده از رکوردهای موجود در آن فراهم خواهد شد.
ایجاد Dataset در هر مرتبه ، بدین معنی است که هر زمان کاربری بر روی یک Button کلیک می نماید ،یک Query و یا Stored Procedure اجراء خواهد شد. مثلا" می توان یک فرم صفحه وب را داشت که کاربر اطلاعات را صفحه به صفحه مشاهده نماید. در صورتیکه هر بار Dataset ایجاد گردد ،فرم های وب یک query را در از منابع داده ئی جهت دستیابی و اخذ رکوردهای بعدی جهت نمایش ، انجام خواهند داد.
در صورتیکه Dataset را ذخیره و مجددا" بازیابی نمائیم ،نیاز به مراجعه مجدد به منبع داده ئی برای اخذ رکوردهای جدید نخواهد بود. ذخیره نمودن یک Dataset دارای چالش های جدی است. یکی از مهمترین چالش ها ،اشغال بخشی از حافظه توسط Dataset خواهد بود( در زمان رفت و آمد صفحه بین سرویس گیرنده و سرویس دهنده ) در صورتیکه Dataset دارای حجم بالائی باشد ،قطعا" حجم بالاتری از حافظه اشغال شده و اگر در چنین وضعیتی چندین کاربر دیگر نیز Dataset هائی را ایجاد کرده باشند ،میزان استفاده از حافظه بمراتب بیشتر از وضعیت قبلی خواهد بود.( یکی از راهکارهای موجود ذخیره داده در صفحه است ). یکی دیگر از چالش های موجود در این زمینه ، مسئله یکسان سازی ( نمودن ) داده های موجود در Dataset با منبع داده ئی است . با توجه به اینکه Dataset تکمیل و حاوی داده های درخواستی بوده و در زمان درخواست کاربر برای داده ها ،Dataset مجددا" Refresh نمی گردد ،این احتمال وجود خواهد داشت که داده های موجود در Dataset یک تصویر زنده از داده های موجود در منابع داده ئی را نشان ندهند .شاید بهتر باشد که برای هر رفت و آمد ،مجددا" Dataset را ایجاد نمود.
● Cache on Server or on the Client
در صورتیکه تصمیم به ذخیره سازی یک Dataset را داشته باشیم ( در زمان رفت و آمد صفحات بین سرویس دهنده و سرویس گیرنده ) می بایست در رابطه با محل ذخیره سازی آن تصمیم مناسب را اتخاذ نمود. مورد فوق به استانداردها و روش های گفته شده در بحث State management برخواهد گشت . در رابطه با ذخیره سازی Dataset دو رویکرد عمده وجود دارد :
▪ بر روی سرویس دهنده ،Dataset را در یک Session State , Application State و یا Cache ذخیره نمود.
▪ بر روی سرویس گیرنده ،Dataset را با استفاد ه از View State و یا فیلد های مخفی ذخیره نمود.
ذخیره نمودن Dataset بر روی سرویس دهنده باعث افزایش استفاده از منابع سرویس دهنده خواهد شد.در چنین حالتی درصورتیکه حجم Dataset بالا بوده و یا کاربران زیادی با Dataset ها ی با حجم کم وجود داشته باشد ، بر کارائی سرویس دهنده اثرات منفی را خواهد گذاشت . استفاده از cache هم مسائل مربوط به خود را دارد چون در صورتیکه سرویس دهنده نیازمند حافظه بیشتری بوده و یا تاریخ اعتبار Cache به پایان رسیده باشد ،مدیریت Cache فضای اشغال شده را آزاد خواهد کرد. بهرحال در چنین مواردی هیچگونه تضمینی وجود نخواهد داشت که Dataset در Cache موجود باشد و می بایست با افزودن منطق مربوطه در صفحات ،در ابتدا بررسی گردد که آیا Dataset در Cache موجود هست یا خیر؟ در صورتیکه Dataset در Cache موجود نباشد ،مجددا" آن را ایجاد و یک نسخه از آن را هم در Cache ذخیره نمود.
ذخیره سازی داده ها در صفحات ، بدین معنی است که ازمنابع موجود بر روی سرویس دهنده برای ذخیره سازی داد ه ها استفاده نشده است . در این روش ، داده ها بعنوان بخشی از Html Stream در صفحات وب قرار خواهند گرفت و اگر Dataset حجیم باشد در زمان لود صفحه در مرورگر و یا ارسال برای سرویس دهنده ، مدت زمان زیادی صرف خواهدشد. در این راستا می بایست این سیاست: "همواره سعی گردد که حجم Dataset به حداقل مقدار خود رسیده و صرفا" رکوردهای مورد نظر را ذخیره کرد " ، مورد توجه جدی قرار گیرد. در مواردیکه می خواهیم یک Dataset را ذخیره نمائیم ،می بایست با افزودن کدهای مربوطه در صفحه ، امکان ذخیره و بازیابی آن را در زمان معقول تحقق بخشید.
در برنامه زیر برای ذخیره و بازیابی یک Dataset از یک Session state استفاده شده است . Dataset با نام dsCoustomer۱ بوده که از یک نمونه کلاس dscoustomer dataset استفاده شده است . توجه داشته باشید که Dataset بعنوان یک شی ذخیره شده است و در زمان بازیابی Dataset می بایست آن را مجددا" به کلاس Dataset تبدیل نمود