Behind every great application lies a database manager. At least it seems that way, especially if your gig is writing Web applications that expose content over the Internet. Amazon.com and eBay are little more than front ends to massive databases designed to serve end users like you and me. The older I get and the wiser I become, the more I realize that programming is about managing and manipulating data, and UI code is just the goo that lets it happen.
Like their counterparts in the unmanaged world, managed applications can and often do utilize industrial-strength databases such as Microsoft SQL Server and Oracle 8i. That鈥檚 why Microsoft created ADO.NET, an elegant, easy-to-use database API for managed applications. ADO.NET is exposed as a set of classes in the .NET Framework class library鈥檚 System.Data namespace and its descendants. Unlike ADO and OLE DB, its immediate predecessors, ADO.NET was designed from the outset to work in the connectionless world of the Web. It also integrates effortlessly with XML, bridging the gap between relational data and XML and simplifying the task of moving back and forth between them.
If you鈥檙e like most developers, you believe that the last thing the world needs is another database access API. Why, when we already have ODBC, DAO, ADO, RDO, OLE DB, and others, do we need yet another API? The short answer is that the world has changed, and none of the existing data access technologies maps very well to a world that revolves around that stateless, text-based protocol called HTTP. In addition, managed applications need an efficient and intuitive way to talk to databases. That鈥檚 ADO.NET in a nutshell鈥攖he database language spoken by managed applications. ADO.NET is an essential component of the .NET Framework. Let鈥檚 see how it works.