This chapter is from the book
This chapter is from the book
This chapter is from the book
Summary
The chapter began with a section illustrating the basic terminology and classes specific to ADO.NET and disconnected data as well as the basics of constructing those objects and connecting to a data source. The next section illustrated how to perform basic database operations (creating, reading, updating, and deleting records). Included in that section were tips on handling the common issues of dealing with disconnected data and auto-increment primary keys, and how to specify primary key information for untyped datasets. The section ended with a fully functional MFC maintenance application using the ADO.NET against a sample database. Once that section was completed, I then illustrated several techniques for reading and writing data in batch in order to keep round trips to the data server to a minimum and dramatically speed up insert operations. As one of the key benefits of an IMDB is its support of the ability to search, sort, and filter data once it's been retrieved, the next section illustrated how to accomplish these tasks as well as how to create multiple filtered views on a single dataset. Finally, the chapter ended with a section on generating strongly typed datasets, using them in an MFC application, and the pros and cons of using untyped vs. typed datasets.
While disconnected data can make applications more complex, it also dramatically improves the versatility and design of client/server and n-tier systems. For example, disconnected data means that systems with thousands of remote clients do not have to worry about how the server is going to attempt to handle so many concurrent connections to the database. In addition, because you can design your system so that the majority of the database operations are done in-memory before updating the database server, you can greatly reduce the number of network round trips. Using disconnected data also enables you to fill a DataTable with data taken from virtually any data source (or even application-generated) and process it with the same routines, regardless of the data's origin. In addition, the decoupled architecture of the DataSet- and DataAdapter-derived classes makes it possible to read data from one source and send updates to another source. These are just a few of the possible scenarios where disconnected data can be a boon for software developers.
Please note that I'm not saying disconnected data is a silver bullet by any means. Every solution to a problem has its own drawbacks. In fact, using disconnected data is flat-out a very bad idea in certain circumstances. Specifically, just as with any other solution that introduces a certain level of complexity to a system, you must weigh the added complexity against the derived benefits. However, for systems—especially n-tier solutions—where both database connections and round trips must kept to a minimum, disconnected data via the ADO.NET class can significantly improve the overall design and execution of the system.
Finally, there's a lot more even to the parts of ADO.NET that support disconnected data than I could possibly convey in a single chapter. However, hopefully you've learned enough in this chapter to decide for yourself if and when ADO.NET and disconnected data are right for you. Now that you know these basics, in the next chapter I'll delve into the more advanced areas of ADO.NET such as merging DataSet objects, reading binary data (especially BLOBs), dealing with concurrency in a disconnected environment, and so on.