Support for ADO in the NET Framework

Introduction

Upgrading existing ADO projects

Using server-side cursors

Accessing an ADO recordset or record from ADO.NET

Performance

With all the features provided by ADO.NET, is there any reason to continue to use ADO? Yes. Here are some potential reasons why.

■ You will not be able to rewrite all of your existing software for the Microsoft .NET Framework.

■ You will need to interact with existing Component Object Model (COM) components.

■ You will not write all of your new software for the .NET Framework.

■ You will need your "legacy" applications to be able to interact with .NET components.

Some scenarios where you will want to interact with existing ADO code, or reuse existing code that uses ADO, are when you want to:

■ Upgrade an existing ADO project.

■ Use server-side cursors directly.

■ Use an existing COM component that returns an ADO Recordset.

If you have existing projects that use ADO, you may want to upgrade the project to use the .NET Framework, while still using the ADO data layer. Although this is not recommended, it can be done through the COM Interop layer.

Another reason for using ADO is if your application requires server-side cursors. The only type of server-side cursor supported by ADO.NET is the forward-only, read-only, "firehose" cursor. ADO.NET does not support dynamic and keyset cursors.

You can create a stored procedure that, because it is executed by the database server, can create and use server-side cursors. Yet, ADO.NET can not create and use server-side cursors directly. This functionality may be added to future versions of ADO.NET. However, misuse of server-side cursors is a major factor in poor scalability of database applications. This is one of the reasons why a design decision was made to exclude this functionality from ADO.NET.

In the .NET Framework, you can access both existing components that return ADO Recordset or Record objects by using .NET COM Interop services and the OLE DB .NET Data Provider. This enables you to use existing COM objects that return ADO objects, without having to rewrite them entirely by using the .NET Framework. ADO.NET and the OLE DB .NET Data Provider only support filling a DataSet from an ADO Recordset or Record object.

Performance of COM Interop in the Common Language Runtime (CLR) has improved dramatically in later betas. ADO is one of the COM Interop team's main scenarios, and the team continues to monitor performance and reliability to make sure this is a valid scenario. In any case, you shouldn't be afraid to use COM Interop to ADO; you just shouldn't be as excited about doing so as you should be about using ADO.NET.

0 0

Post a comment