برای فهمیدن تکامل به سمت 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 کار می کند.
