تفاوت های بین ADO و ADO.Net

تفاوت های بین ADO و ADO.Net
ADO بر اساس معماری Microsoft COM با واسط های OLE DB بنا نهاده شده است، در حالی که ADO.NET بر اساس معماری Microsoft.NET و مشخصأ واسطهای ADO.NET بنا نهاده شده است. از آنجائیکه معماری .NET کاملأ با معماری COM متفاوت می باشد، واسطهای ADO.NET کاملأ متفاوت از واسطهای ADO و OLE DB می باشند. این در ضمن بدین معنی است که Data Provider های ADO.NET کاملأ با Data Provider های ADO متفاوت می باشند. قبل از اینکه ما وارد جزئیات بین ADO و ADO.NET شویم، شاید نگاه کردن به تاریخچه اتصال داده مطرح شده در Platform مایکروسافت خالی از منفعت نباشد.

تاریخچه مختصری بروی معماری های اتصال داده ای
ODBC- اتصال پایگاه داده ای باز (Open Database Connectivity) اولین تکنولوژی دستیابی به داده می باشد که یک واسط مشترک استاندارد از طریق SQL برای دستیابی به پایگاه های داده رابطه ای همگن تهیه کرد. بوسیله ODBC، یک کاربرد می تواند به پایگاه های داده مختلف از طریق یک مجموعه ساده ای از کدهای مشترک دستیابی پیدا کند. توسعه دهندگان جهت متصل کردن کاربرد به داده انتخابی کاربر تنها نیازمند اضافه کردن درایورهای ODBC می باشند. امروزه ODBC در میان بیش از دوازده Platform و چندین پایگاه داده فراهم می باشد. معماری عمومی آن در شکل 1 بیان شده است:

– معمارى ODBC

DAO- ODBC بیشتر برای برنامه نویسان C و C++ که مجهز به تکنیک های فراخوانی سطح پایین می باشند تدارک دیده شده است. DAO و یا به عبارتی Data Access Object که بوسیله مایکرسافت تهیه شده است راهی بود که برای توسعه دهندگان Visual Basic تدارک دیده شد که بتوانند به سادگی به داده ها دستیابی پیدا کنند. در واقع به برنامه ها این توانائی داده شد که بتوانند بدون استفاده از متغیرهای نوع اشاره گر به پایگاه داده Access متصل گردند (Access نیز به عنوان Jet Engine شناخته شده است). برای استفاده از پایگاه داده های دیگر، می توان DAO، ODBC و Jet Engine را همانند شکل 2 بکار برد.

– معماری DAO

RDO – برای دستیابی به یک دامنه گسترده ای از پایگاه داده های رابطه ای با استفاده از DAO، Jet Engine می بایست فراخوانی های بین DAO و ODBC را ترجمه می کرد، که این خود معرف یک کاهش کارائی بود. برای غلبه بر این محدودیت، مایکروسافت Remote Data Object (RDO) را معرفی کرد. RDO بدون طی کردن مسیری از میان Jet Engine (همانند شکل 3) به ODBC دسترسی پیدا می کرد.

– معماری RDO

OLE DB – در طی سالیان، ODBC در ارتباط برقرار کردن با پایگاه های داده خوب عمل کرد. اما هرچه گذشت داده ها در فرمت های غیر رابطه ای بیشتر ذخیره گردیدند، همانند Microsoft Exchange Server، بدین سان یک معماری جدیدی نیاز بود تا یک ارتباط بدون نقصی را در میان منابع داده ای متفاوت و کاربردهای مختلف فراهم سازد. OLE DB بلاک سازنده و زیربنائی مدل شئی کامپوننت برای ذخیره سازی و بازیابی رکوردها می باشد و درواقع دستیابی یکسانی را به پایگاه های داده رابطه ای، غیر رابطه ای و منابع داده ای غیر ساخت یافته در میان تاسیسات مختلف فراهم آورده است. OLE DB پیرو موفقیت ODBC معرفی گردید. معماری این تکنولوژی در شکل چهار بیان شده است:

– معماری OLE DB

ADO- OLE DB چندین تکنیک فراخوانی سطح پایین را بکار برده است که همین امر برنامه نویسی را وحشتناک ساخته است، بخصوص برای برنامه نویسان نوع Visual Basic. برای غلبه بر این مشکل، مایکروسافت ActiveX Data Object یا به عبارتی ADO را معرفی کرد. ADO بروی سر OLE DB فعالیت می کند و واسط سطح بالاتر و ساده تری را همانند شکل 5 فراهم می آورد:

– معماری ADO

تفاوت های ADO.NET با ADO در چیست؟
از زمانی که معماری .NET شروع به طراحی شد، مایکروسافت تصمیم گرفت که مدل دستیابی به داده خودش را مجددأ طراحی کند. پیرو این تصمیم بجای اینکه بیشتر بروی توسعه ADO فعالیت کند، مایکروسافت تصمیم گرفت که یک معماری دستیابی داده جدیدی را بر اساس چهارچوب جدبد .NET طراحی کند – اما مایکروسافت همچنان لغت خلاصه ADO را مورد استفاده قرار داد. مایکروسافت ADO.NET را بر اساس تجربه موفق مدل شئی ADO طراحی کرد، اما با یک معماری کاملأ متفاوت، مبتنی بر XML و مدل محاسبه غیر پیوسته . معماری جدید راه های متعددی را برای اتصال یک کاربردی که می خواهد به یک منبع داده متصل گردد فراهم آورده است، همانند شکل 6:

– معماری ADO.NET

برای فهمیدن تکامل به سمت ADO.NET، شناخت بعضی از نکات بر مبنای ADO که در طراحی این تکنولوژی پیشگام بوده است بسیار مهم است. ADO از Recordset ها و کرسرها برای دستیابی و تغییر دادن داده ها استفاده می کند. به علت ماهیت طراحی، Recordset می تواند کارائی را در سمت سرور بوسیله مصرف قابل توجهی از منابع کاهش دهد. علاوه بر این، عمل COM Marshaling (که یک پروسه تبدیل داده پر هزینه ای می باشد) برای انتقال یک Recordset مورد نیاز می بود. مایکروسافت بوسیله اضافه کردن پشتیبانی هائی برای XML در ADO 2.1سعی کرد که طراحی خود را بهینه نماید. به هر جهت، پشتیبانی به عمل آمده از XML محکم و قابل اعتماد نبود و استفاده از XML محدود به چندین محدودیت متعدد بود.
ADO.NET سه نیازمندی مهمی را که ADO مشخص نمی ساخت مورد اشاره قرار داد:

  • تهیه یک مدل دستیابی به داده غیر متصل (Disconnected )، که در محیط های وب بسیار بحرانی می باشد
  • تهیه یکپارچه سازی بسیار محکم با XML
  • تهیه یکپارچـه سـازی بدون درز با چهـار چوب .NET (برای مثال : قابلیت انطباق با کتابخانـه هـای نوع سیستمی کلاس پایه)

از دیدگاه پیاده سازی ADO.NET، شئی Recordset در ADO از معماری .NET حذف شده است. در این جا، ADO.NET دارای چندین شئی تخصیص داده شده می باشد که در ارتباط با شئی Dataset مطرح شده اند و شامل اشیاء Data Adaptor، Data Reader ای می باشد که کارهای خاصی را انجام می دهند. علاوه براین، اشیاء Dataset، ADO.NET، در یک حالت غیر متصل کار می کنند، در حالی که اشیاء Recordset، ADO در یک حالت کاملأ متصل فعالیت می کنند.
بعلت تفاوت های اساسی موجود در COM و .NET (به همین ترتیب تفاوت های اساسی در معماریADO و ADO.NET وجود دارد)، یک تکنولوژی کاملأ جدید برای دستیابی به داده ها از طریق Platform، .NET مورد نیاز می باشد. در حقیقت، نیازمندی وجود تکنولوژی Data Provider ADO حذف شده است. در حالی که یک تهیه کننده داده ADO بر مبنای COM بوسیله C++ و بوسیله کتابخانه های COM توسعه داده خواهد شد، تهیه کننده داده ADO.NET تنها نیازمند نوشته شدن بوسیله کتابخانه های کلاس پایه چهارچوب .NET می باشد و طوری طراحی شده است که کاملأ درون پارامترهای زبان مشترک زمان اجرا می تواند فعالیت کند. علاوه بر این، محیط ADO.NET به صورت پیش فرض طوری طراحی شده است که به جای کار با انواع محلی سیستمی ADO با فرمت XML کار می کند.

خلاصه

ADO.NET، XML را جهت فراهم آوردن دستیابی به داده بهینه شده در چهارچوب .NET تقویت کرده است . از آنجائیکه معماری پایه از COM به .NET به صورت زیربنائی متفاوت می باشد، تهیه کننده های داده ADO.NET نیز محصولاتی کاملأ متفاوت از تهیه کننده های داده ADO قدیمی می باشند. سازمان هائی که تصمیم بر مهاجرت به .NET دارند و مراقب جامع بودن توابع و کارائی آن هستند نیامند سرمایه گذاری بروی تهیه کننده های داده جدید ADO.NET هستند.

مدرس دانشگاه مهندس حامی امینی

amini@kawacomputer.com

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

اجرا شده توسط: همیار وردپرس