Writing a Simple Data Provider

Afterword

Some Final Thoughts on the Future of ADO.NET

For a programmer who builds data-centric applications, the development of ADO.NET marks a technological quantum leap. Its object model is elegant and clean, and language neutral. The resultant ADO.NET object model is also powerful and effective but, believe me, that s just one of its many advantages over ADO.

Prior to ADO.NET, the programmer had to opt for ease of development or choose fast, but quirky and error-prone, code that was arduous to write. You could either take the Visual Basic route and fall into the capable hands of ADO or you could be a brave and intrepid programmer and take the enlightening journey into the depths of OLE DB. With .NET, you no longer have to choose between the lesser of two evils. ADO.NET provides a common API for writing data-driven applications no matter what the application model Web forms, Windows desktop applications, or Web services. The language neutrality of .NET makes the question about what came first the Visual Basic egg or the C++ chicken irrelevant. ADO.NET takes the best of both worlds and weds the simplicity of ADO to the effectiveness of raw OLE DB. In doing so, it also gets rid of the code that made ADO somewhat slow, and abstracts the data model that made OLE DB somewhat tedious to understand and boring to use.

For those of us who invested time and money in ADO, the introduction of ADO.NET is a double-edged sword. On one hand, we can appreciate the power and modern design of the object model. But on the other hand, the switch to ADO.NET, turns most ADO code into legacy code. It doesn t matter when the code was written; legacy is a timeless concept, and we are all writing code today that will be marked as logically obsolete by the time we finish it. Logically obsolete is not a condition that invalidates code; fortunately, the code will still work. It simply means that if you keep writing the same code, you re going to end up at a dead-end. Of course, you can always change course and the good news is that while we can t reuse our existing ADO code, we can transfer our ADO skills to ADO.NET. Our knowledge never becomes obsolete.

A key question for someone contemplating switching to ADO.NET is: Can we really rely on ADO.NET, or is it just another trendy data access layer for this summer s applications? In recent years we have observed a proliferation of data access models, and ADO looked like the definitive tool based on two now-and-forever underlying technologies: COM and OLE DB. Of course, in late 1998 when ADO 2.0 was introduced, no one could have predicted the .NET thunderstorm. But now, as we look into the eye of this storm, we realize that to determine its future, we need to weigh its advantages and see its growth potential.

In several aspects, ADO.NET is a better and richer model than ADO. But are they functionally equivalent? The answer is no. To compare their functionality, we have to talk about the schema object model (ADOX) and server cursor support.

Today, to manipulate the database schema from within .NET applications, you have to come up with work-arounds. You can issue provider-specific queries and work in read/write manner. One alternative is to read (only) schema information through the OLE DB .NET data provider and the adapter s GetOleDbSchemaTable method, or you can use COM Interop Services to call into the COM-based ADOX object model. In the future, ADO.NET will provide read/write access to table schema information using a .NET object model based on DataSet, Table, Column, and Constraint objects.

Server cursors are not supported in ADO.NET. For positioned updates and long lock operations, you can use multiple SQL statements and keep connections and transactions open; however, a new bunch of ad hoc objects are on the way. The principal behind these ad hoc objects is the ResultSet which is a provider-specific scrollable and updateable server cursor. Each .NET data provider will be exposing its own implementation of such an object in much the same way as today s .NET data providers expose data readers and data adapters. A ResultSet will work in a similar way as the writing counterpart of today s reader objects. Such a data-writer object would allow an application to position on a record, read/write its value, and persist updates.

So much for the question of functionality, however, we also need to ask what is the key advantage of the ADO.NET object model over ADO. The answer to this question is the argument we poor programmers can use to convince our bosses to give us the green light for the adoption of ADO.NET. Well, in ADO.NET version 1.0 there is a small, but potentially explosive, feature that will be significantly expanded in future versions. The feature I m referring to is called typed DataSets.

A typed DataSet is a .NET class built atop the DataSet class. It inherits all the methods, events, and properties of a DataSet and provides strongly typed methods, events, and properties. Each table and column becomes a child object of this data-specific object and can be accessed by name instead of using ad hoc, but necessarily generic, collections like Tables, Columns, and Rows.

A typed DataSet does not necessarily give you more programming power. It does however improve the readability of the resultant code and, when used within Visual Studio .NET, activates the IntelliSense technology and provides auto-completion. In addition, with a typed DataSet, type mismatch errors are caught at compile time rather than at run time. Creating typed DataSets today requires the use of a command-line tool (also buried in the Visual Studio.NET interface) to generate a new class from an inferred XML schema. Aside strongly typed access to data, a second key feature of typed DataSets is that you can use them to expose data inside a DataSet as stand-alone objects. These features will be expanded a bit in the next versions of ADO.NET and evolve into a new software entity called the object space. The object space will dynamically generate the necessary code at run time. It contains objects to store, update, and query data realizing a neat separation between business logic and data access code. Relationships and constraints will still be supported and automatically enforced. A new object query language that has explicit recalls to XPath completes the package. From the programmer s standpoint, you create only an entry point to the object space and then move within the space using a common and generic set of methods. Schema and code that proves to be necessary for further operations is generated on the fly.

There s still a lot you can expect from ADO.NET, and the goal is to make effective data access as smooth and productive as possible. In this final chapter, I ve quickly outlined the future developments of ADO.NET. But ADO.NET as it comes out of the box in .NET Framework 1.0 is already a big deal. Enjoy, but stay tuned for more!