Wrapper for ADO to ADO.Net

[varshan09]

We are doing migration for a VB application in which we need to migrate ADO objects to ADO.Net objects.

Has anybody used any such wrapper that gives feature of ADO and is implemented in ADO.Net?

THanks
Varsha

 

[sodakotahusker]

Do you mean you want code written in vb.net to call ado ?
Or vb6 code to call ado.net code?

 

[varshan09]

What I mean is, we will write a custom class with the name of ADODB which will have all the properties and methods supported by ADO objects. However, implementation of these methods will have ADO.Net objects.

Has anybody already worked on it?

 

[sodakotahusker]

Yes I did it with my first VB.NET project. ADO is a COM based solution. Using the COM interOP lets you use any COM objects with dot.net .

 

[varshan09]

Actually we don't want to use COM interop. We want to write a custom class without any reference to the ADO object in the application.

Just curious to know, if it is possible to remove reference of ADO objects with interop?

Thanks
Varsha

 

[sodakotahusker]

ADO and ADO.NET are two different animals.

The recordset of ADO exists no more.

If you are bringing data into your application, the only way you could write code the way you describe is by returning all of your data in arrays or assigning all individual fields in your class module (and that would be a pain in the butt - just as easy to move to ado.net now). So only that module references ADO. If you are just calling stored procedures to execute inserts, updates, deletions - then what you are proposing would be easier - but that does not seem like a real life scenario.

 

[ThatRickGuy]

If I understand what you want to do, It can be done. The question is should it. I know the pain that is migrating from ADO to ADO.Net, but that pain forced me to re-examine how I was handling data at the application level. Now, I have 2 classes that do all of the acutal ado.net code (One for SQL Sever, and one for OLEDB) All of my interaction takes place in an abstraction layer. So the App calls business objects, the business objects call data objects, the data objects call the appropriate data abstraction object, and that object calls the proper data base.

The joy is that I can create a set of data objects for tables on different databases, even in different types of data bases. I can then take those data objects and plug them into any app I make and have instant access to the database with out having to type a single line of ADO.Net code. With this template style we kicked out 20+ data gathering reports in under a week.

So as much as I prefer the 3 object model joy of ADO, I also appreciate the change in coding style that ADO.Net drove me too. That and under the hood, ADO.Net better performing and has some great tools.

-Rick

----------------------

http://www.ringdev.com