| In this chapter we introduced ADO.NET generally and the objects of a .NET Data Provider in particular. Data providers are the ADO.NET interface to physical data stores and provide a connected mode programming model. We explored with you the properties and methods of the Connection, Command, Parameter, DataReader, and Transaction objects, including examples involving the standard SqlClient, Oledb, and Odbc Data Providers. In Chapter 5, we show how the disconnected programming model, based on the DataSet and DataAdapter objects, builds on these objects and examples. Questions and Answers | Q1: | What I understand from this chapter is that ADO.NET is really designed for disconnected use and that there is no support for server-side cursors or pessimistic locking. What do I do if my existing application uses one of these, or if the specifications of my new project require server-side cursors or pessimistic locking? Am I stuck with Visual Basic 6.0? | | A1: | First of all, carefully analyze your application and be sure that you aren't stuck in an old way of thinking that you aren't just used to always using pessimistic locking or server-side cursors. If, however after thinking about the options you're convinced that you require either one of them, or something else that ADO.NET doesn't support, don't give up. You can still use VB.NET for these applications. The .NET Framework includes extensive support for COM interoperability, which allows your .NET application to utilize COM objects and for your COM objects to utilize managed (.NET) code. In other words, you can continue to use not only ADO 2.X, but also any other COM objects for which you don't yet have .NET replacements. Of course, there is no free lunch, and the price to be paid is the performance hit you will suffer when going between the two (COM and .NET) worlds. Is it too much of a performance degradation? Like most performance questions, the answer is that you have to test it for yourself with your specific application. | | Q2: | Programming the objects, methods, and properties discussed in this chapter doesn't seem all that different from what I have been doing with ADO 2.X. Why should I bother making the switch to ADO.NET? | | A2: | In one sense, you're right. Performing these same basic connected-to-the-database operations isn't much different from using ADO 2.X. However, in addition to the minor improvements and conveniences that we've mentioned, you should keep several important points in mind. Visual Basic.NET and the .NET platform is a whole new world, and ADO.NET is the way to access data in this world. Although you can continue to use existing COM components such as ADO 2.X while developing .NET applications, you will still suffer performance overhead in accessing these COM components and the need to install and register them properly. The data provider objects discussed in this chapter are only part of the story, dealing with physically reading from and writing to the database in a connected mode The other part of the story, the disconnected mode of operation centered on the DataSet object, is where ADO.NET really shines and has many obvious advantages. We needed to cover this chapter's basic objects first, as they are the necessary building blocks for what comes next. |
|