Plan and carry out a gentle migration from ADO to ADO.NET
Many existing applications, especially Web and n-tier applications, use ADO as the preferred way of interacting with database management systems. ADO was created for use with connected and mostly two-tier applications. Over time, Microsoft extended the ADO object model design to meet new user requirements such as support for disconnected scenarios, n-tier development, and XML integration. The Microsoft .NET Framework, however, presents a new object model, raising crucial questions for developers and software architects: To port or not to port? Should you port applications gradually or rewrite them from scratch? Should you stay with ADO, or should you go with ADO.NET?
The .NET Framework comes with a new data-access layer that two main groups of classes—the ADO.NET and XML core classes—provide. Under the umbrella of ADO.NET, you find classes such as DataSet and DataTable that implement database-independent data containers. You also find database-oriented tools such as SQL and OLE DB commands, managed data providers and connections, data readers, and data adapters. ADO.NET represents the .NET way of working with data irrespective of data source, data format, or physical location. It comes with a new object model and, more important, pushes new concepts such as the DataSet and the DataReader. It also features a data-centric design center different from ADO's database-centric vision and closer to today's Web programming needs.
Starting with beta 2, ADO.NET has provided some interesting options to import ADO code and convert ADO objects into ADO.NET classes that are more usable in .NET applications. Because of this conversion ability, backward compatibility is guaranteed. Although ADO and ADO.NET are substantially different, they possess objects whose roles are functionally similar. At the highest level of abstraction, the way you access data in ADO.NET isn't much different from the way you access it in ADO.
To use ADO objects from within .NET applications, you need to be familiar with some tools and techniques. Although functional, using ADO in .NET isn't a recommended practice; apply it only as a transition step on the way to a full porting of the application to ADO.NET. Let's look at the tools first; then I'll demonstrate a powerful technique for importing an ADO Recordset object into an ADO.NET DataTable object. This importation is ideal if you have middle-tier COM objects to deal with in your applications.
Using ADO from ADO.NET
Although rich and powerful, the ADO.NET object model doesn't cover all the functions of ADO. For example, at least in version 1.0, ADO.NET lacks support for server cursors and the ADO Extensions (ADOX) object model that you can use to programmatically manage table schemas. If you can't work around these problems and you still need to begin porting the application to .NET, you must stick with ADO and find a way to use the application from .NET.
ADO objects are contained in a COM library called msado15.dll, which is usually in the C:\program files\common files\system\ado folder. Don't be fooled by the 15 in the DLL's name: It doesn't mean that your version of ADO is 1.5, nor that you're looking at the wrong file. Any later version of ADO (from 2.1 to 2.7) resides in a file with that name.
To use ADO in .NET applications, you need to create a class, wrapping it as a .NET-compliant class, because .NET applications can't just call COM objects such as those in the ADO library. After you install the .NET Framework, you have a managed executable file called adodb.dll in the C:\program files\microsoft.net\primary interop assemblies folder. This file is what you need to import ADO code into any model of .NET application—Windows Forms, Web Forms, and Web Services. Especially if you're still using beta versions of .NET for test and evaluation purposes, you might not have the right version of the adodb.dll file. You can regenerate this file at any time by using a .NET Frameworkprovided utility, tlbimp.exe. You run the utility from the console command line as follows:
tlbimp "C:\Program Files\Common Files\Systemado\msado15.dll"
The tlbimp.exe utility is available in the Bin subdirectory of the path where you installed the .NET Framework. Usually, this path is C:\program files\microsoft visual studio .net\frameworksdk\bin. The adodb.dll file contains .NET classes that expose the same programming interface as the original COM-based ADO library. Your .NET application talks to these classes, which in turn communicate with ADO objects.
Prev. page
[1]
2
3
4
next page 
