Building Web Solutions with ASP.NET and ADO.NET

Building Web Solutions with ASP.NET and ADO.NET

 

Part 1 Data Access and Reporting

Chapter 1 Data Bound .NET Controls
Chapter 2 Pageable Data Grids
Chapter 3 Templated DataGrid Controls
Chapter 4 Editing DataGrid Controls

 

Part 2 Smart and Effective Data Access and Reporting

Chapter 5 Code Reusability in ASP.NET
Chapter 6 Advanced Data Reporting
Chapter 7 Disconnected Web Applications

 

Part 3 Interoperability

Chapter 8 Interoperable Web Applications
Chapter 9 Web Services
Chapter 10 Exposing Data to .NET Applications

---

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 t he 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.