دنیای کامپیوتر - شبکه - برنامه سازی

در اغلب فرم های وب نياز به دستيابی داده ها و نمايش آنها و در برخی موارد ويرايش و بهنگام سازی آنها وجود خواهد داشت . آگاهی از تکنولوژي های دستيابی به داد ه ها در صفحات فرم های وب،  باعث طراحی و پياده سازی نرم افزار های موثر و با کارائی بيشتر تحت وب خواهد شد. در اين مقاله به بررسی مفاهيم مربوط به دسيتابی داده ها در صفحات فرم های وب پرداخته و نحوه استفاده از کنترل های مربوطه جهت نسبت دهی داده ها در صفحات را بررسی خواهيم کرد.
فرم های وب ، اغلب ملزم به نمايش اطلاعاتی هستند که ماحصل بازيابی آنان از يک منبع داده ئی نظير يک بانک اطلاعاتی و يا يک سند XML خواهد بود. ساختار و معماری صفحات فرم های وب اين امکان را فراهم می نمايد که با اتکاء به برخی روش ها از منابع متفاوت داده ئی در صفحات استفاده و با نسبت دهی  کنترل ها به داده ها و پردازش داده های مورد نظر، امکان انجام عمليات دلخواه و مرتبط با داده ها را بسرعت و با کيفيت بالا انجام داد. دستيابی به داده ها در فرم های وب با دستيابی به داده ها از طريق فرم های ويندوز و ساير برنامه های تحت ويندوز متفاوت بوده و همين امر يکی از وجوه تمايز اساسی بين برنامه های تحت وب با ساير برنامه ها است.
اصول اوليه دستيابی به داده ها در صفحات فرم های وب
دستيابی به داده ها در صفحات فرم های وب با تاکيد بر اصول اساسی زير انجام می گيرد:
▪ استفاده از يک مدل Disconnect
▪ خواندن بيشتر داده ها نسبت به ويرايش آنها
▪ به حداقل رساندن استفاده از منابع موجود بر روی سرويس دهنده
▪ دستيابی به داده ها با استفاده از پردازش های راه دور( دستيابی به داده های توزيع شده )
در ادامه به تشريح هر يک از اصول فوق خواهيم پرداخت .

Disconnected Model . صفحات فرم های وب از نوع Disconnect می باشند. پس از درخواست يک فرم وب از طرف سرويس گيرنده و ارسال درخواست برای سرويس دهنده ، فرم ايجاد ،پردازش ،ارسال و در نهايت از حافظه سرويس دهنده حذف خواهد شد. نحوه دستيابی به داده ها در يک صفحه فرم وب نيز حکايتی اينچنين دارد. در اين راستا و در زمان پردازش فرم بر روی سرويس دهنده ، داده ها ی مورد نظر خوانده و يا ويرايش شده و در نهايت فرم برای متقاضی ( سرويس گيرنده ) ارسال خواهد شد. در چنين حالتی داده ها بر روی سرويس دهنده حذف خواهند شد ( از درون حافظه و يا بافر های استفاده شده برای پلسخگوئی به درخواست ) .
مدل فوق دارای چندين نکته مهم بوده که شناخت آنان برای موارديکه در صفحات فرم های وب با داده ها سروکار داريم ، بسيار مفيد خواهد بود.
▪ داده هائی که قصد استفاده از آنان را خواهيد داشت،  بصورت خودکار و پس از رفت و آمدهای متعدد بين سرويس گيرنده و سرويس دهنده ،قابل دستيابی نخواهند بود. در صورتيکه بخواهيم به داد ه ها دستيابی داشته باشيم می بايست هر زمان که صفحه برای سرويس دهنده  پست می گردد ، مجددا" داده ها از منابع مربوطه خوانده شوند. در اين راستا می توان با نوشتن کدهای اضافه که در صفحه مستقر خواهند شد ،اقدام به ذخيره سازی داده ها نموده و در زمان پردازش فرم و از طريق کدهای نوشته شده مجددا" به آنها دستيابی پيدا کرد.
▪ در زمان پردازش می توان با منابع داده ئی يک ارتباط برقرار و پس از خواندن و يا نوشتن داده ها ،اقدام به بستن ارتباط ايجاد شده با منابع داده ئی نمود. تصور اينکه ارتباط با منبع داده ئی را فعال نگه داشته تا در آينده بتوان مسائل مربوط به مديريت داده ها و دستيابی به داده ها را بهبود بخشيد ، نادرست و انتظاری نامعقول است .
▪ در زمان رفت و آمد يک صفحه بين سرويس گيرنده و سرويس دهنده عمليات مربوط به دستيابی به داده ها انجام خواهد گرفت . مثلا" در اولين مرتبه که صفحه صدا زده می شود ،ممکن است داده ئی از منبع مورد نظر خوانده و کنترل های موجود بر روی صفحه را به آن نسبت داد،زمانيکه کاربر کليدی (Button) را فعال نمائد،  می توان داده ئی را از يک کنترل گرفته و در منبع داده ئی ذخيره نمود.
 

خواندن و بهنگام سازی داده ها . در اغلب فرم های وب ، نوع دستيابی به داده ها بصورت فقط خواندنی است . در مواردی هم ممکن است کاربر داده ئی را برای ثبت ، درج و يا بهنگام سازی در منبع داده ئی ارسال نمايد. چون اغلب عمليات دستيابی به داده ها بصورت فقط خواندنی است ،معماری Data-Binding ( نسبت دهی داده ها )  در فرم های وب ، پاسخی به اين نياز بوده است . بدين ترتيب Data-Binding ، باعث نمايش داده ها در کنترل مربوطه خواهد شد. بهنگام سازی داده ها قطعا" Overhead در يک صفحه را افزايش خواهد داد. در چنين حالتی صفحه می بايست دارای چندين نسخه از رکوردها برای ويرايش و همچنين شامل منطق مربوط برای انجام عملياتی نظير : درج و حذف رکوردها باشد. بدليل افزايش لود بر روی صفحات ، بخشی از حافظه اصلی بر روی سرويس دهنده و ساير منابع مورد نظر بخدمت گرفته خواهند شد.

به حداقل رساندن ميزان استفاده از منابع موجود بر روی سرويس دهنده .صفحات فرم های وب ، قبل از ارسال برای مرورگر سرويس گيرنده می بايست بر روی سرويس دهنده پردازش گردنند. هر نوع عملياتی که منجر به دستيابی به داده ها در صفحه گردد ، باعث افزايش لود عملياتی سرويس دهنده از دو بعد زمان پردازش و استفاده از حافظه خواهد شد. در مواردی هم که نياز به ذخيره سازی داده ها باشد استفاده از منابع در زمانی که صفحات پردازش نشده اند نيز وجود خواهد داشت . دستيابی به داده ها در صفحات فرم های وب نيازمند يک بررسی دقيق و کارشناسی و نحوه استفاده از منابع است . در اين راستا دو اصل زير را می توان همواره مد نظر داشت :

▪ در هر صفحه صرفا" به بخشی از اطلاعات که لازم است، دستيابی و از اخذ اطلاعات غيرضروری و گاها" حجيم در يک صفحه وب ، اجتناب ورزيد.
▪ در صورت امکان از گزينه های state management ( متکی بر سرويس گيرنده ) استفاده گردد.
صفحات وب در لايه نمايش يک برنامه تحت وب عمل کرده و می توان از طريق آنان به داده ها دستيابی پيدا کرد در اين راستا ترجيح داده می شود که منطق دستيابی به داده ها را از بخش UI بکمک استفاده از عناصر ديگر نظير سرويس های وب Xml و ... تفکيک نمود.
صفحات فرم های وب، بعنوان يکی از اجزای دات نت ،داده های خود را با ساير عناصر پردازشی از طريق يک جريان ممتد Xml انجام می دهند. در اين زمينه نياز به اقدام مستقيم جهت کار با Xml نخواهد بود( ارتباط بين اجزاء). فريمورک صفحات وب ( DataSet ) تبديلات فوق را بصورت خودکار انجام خواهد داد. در صورت نياز و در موارد خاص می توان دستيابی به داده ها را در يک برنامه تحت وب، مستقيما" با فرمت Xml انجام داد.


منابع داده (Data Source) برای صفحات فرم های وب
معماری صفحات فرم های وب، امکانات کاملا" انعطاف پذيری را در رابطه با داده ها ارائه نموده است . امکانات فوق از دستيابی به بانک های اطلاعاتی سنتی تا استفاده از سندهای متکی بر Xml تا اخذ اطلاعات در زمان اجراء و ذخيره آن در يک بردار را شامل می شود.
▪ دستيابی به بانک های اطلاعاتی . برای خواندن و نوشتن داده ها از بانک های اطلاعای از ADO.NET استفاده می گردد. ADO.NET شامل امکانات لازم جهت مديريت داده ها ( ارتباطات و اشياء مورد نياز ) جهت ارتباط با سرويس دهنده SQL و يا يک بانک اطلاعاتی سازگار با OLE-DB است . ADO.NET همچنين امکاناتی را برای دستيابی به داده ها از طريق يک Dataset ( در اين حالت يک ارتباط دائم و پيوسته با بانک اطلاعاتی وجود نخواهد داشت ) که داده ها در بخشی از حافظه Cache شده اند ،را پيش بينی نموده است . امکان استفاده از اشياء ADO.NET بمنظور اجرای دستورات SQL و يا Stored procedure بصورت مستقيم نيز وجود خواهد داشت .
▪ XML Data . يکی ديگر از منابع داده ئی در صفحات فرم های وب ،استفاده از سندهای Xml است . بمنظور استفاده و کار با اين نوع سندها می توان از دو روش عمده زير استفاده نمود:
● در صورتيکه داده های Xml ساختيافته باشند ،می توان آن را به يک Dataset تبديل و با استفاده از توابع داده ئی ADO.NET عمليات مربوط به خواندن و يا بهنگام سازی داده ها را انجام داد.پس از انجام عمليات مورد نظر می توان مجددا" داده ها را به فرمت Xml تبديل تا قابل استفاده برای ساير پردازش هائی باشند که قصد استفاده از اين داده ها را دارند.
● در صورتيکه داده ای Xml ساختيافته نباشند ،می توان از توابع مربوط به Parse نمودن و پردازش در System.Xml ( يک NameSpace است ) جهت انجام عمليات دلخواه بر روی داد ه ها استفاده کرد. در صفحات فرم های وب ، می توان اين کار را از طريق استفاده از کنترل های سرويس دهنده وب Xml انجام داد.
▪ ساير منابع داده ئی . صفحات فرم های وب ، اين امکان را فراهم می نمايند که بصورت مجازی با ساير داده ها نيز ارتباط برقرار  گردد. معماری Data Binding در صفحات فرم های وب اين امکان را فراهم می آورد که يک کنترل را به هر نوع ساختاری بتوان نسبت داد. مثلا" می توان هر نوع برداری را به يک کنترل نسبت داد. بمنظور انعطاف  بيشتر می توان Data binding را در زمان اجراء انجام داد . هر کنترل ، يک رويداد Data Binding را حمايت خواهد کرد.با نوشتن Handler مربوطه برای اين رويداد می توان کنترل هائی را برای هر صفحه و هر نوع داده انجام  داد.

استراتژی  دستيابی به داده ها در وب
در زمان طراحی و پياده سازی يک برنامه تحت وب و بمنظور دستيابی به داده ها ، چالش های  متعددی وجود دارد: نحوه ارتباط با يک منبع داده ، نحوه ذخيره سازی داده ها در زمان رفت و آمد صفحات بين سرويس گيرنده و سرويس دهنده ، محل ذخيره سازی داده ها در صورت تاکيد بر ذخيره سازی داده ها و ... . نحوه برخورد با چالش های فوق  و انتخاب راهکارهای متاسب ،  در طراحی و پياده سازی يک برنامه تحت وب تاثيرات خود را بدنبال داشته و می تواند در نحوه اجراء و کارائی برنامه ، پيامدهای مستقيمی را داشته باشد.
برای دستيابی به داده ها يک استراتژی ثابت و منفرد که در تمامی حالات پاسخگو باشد ،وجود نداشته و با انتخاب هر رويکرد می بايست پذيرای نکات مثبت و منفی آن نيز بود. در ادامه به بررسی اصول اوليه در طراحی صفحات فرم های وب بمنظور دستيابی به داده ها خواهيم پرداخت .

● ? 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 با نام dsCoustomer1 بوده که از يک نمونه کلاس dscoustomer dataset استفاده شده است . توجه داشته باشيد که Dataset بعنوان يک شی ذخيره شده است و در زمان بازيابی Dataset می بايست آن را مجددا" به کلاس Dataset تبديل نمود.