Hitchhikers Guide to Visual Studio and SQL Server: Best Practice Architectures and Examples, 7th Edition (Microsoft Windows Server System Series)

To get a better understanding of the ADO.NET namespaces, I suggest that you open Visual Studio and the Object Browser (View | Object Browser), where you'll see a window similar to that shown in Figure 8.2. By using the OB, you can get a better idea of how to address a specific Framework class, get (limited) help on selected objects (via F1), and view the properties, functions, methods, and events of the objects. Don't be alarmed at the sheer volume of classes in the Framework. While I've never counted them, I understand there are over 70,000 of these classes, depending on what's included in the total. Sure, you can gain a complete understanding of ADO.NET development without memorizing these namespacesbut there will be a test on them later.

Since this book focuses on SQL Server, I spend considerable time discussing the SqlClient .NET data provider and far less time discussing the OleDb or Odbc providers. Frankly, my previous books on ADO.NET^[2] provide quite a bit of detail on these other providers and how to connect to their data sourcesI won't be revisiting that material here. Once connected, the functionality between providers is very similar, so the concepts you learn when working with SqlClient are similar to those applied to OleDb and Odbc.

^[2] ADO and ADO.NET Examples and Best Practices for Visual Basic Programmers (Apress, 2002) and ADO.NET Examples and Best Practices for C# Programmers (Apress, 2002).

Exploring ADO.NET with a Class Diagram

Visual Studio 2005 includes a new tool called the "Class Diagram" that shows the interrelationships between the base and working classes I code against. If your application builds a number of classes (especially when you're coding complex classes), the Class Diagram tool can make it easier to visualize the classes and their interrelationships, and actually generate your own classes from scratch. If you don't use it for anything else, a Class Diagram can be an effective way to document your classes. I won't have time to teach you how to use the Class Diagram, but I do want to touch on it briefly to give you an idea of its power. To that end, let's create a simple Class Diagram using the Object Browser and a new Class Diagram tool.

Okay, what can be learned from the diagram in Figure 8.4? Well, notice that the DbConnection class implements several properties and methods that are common to all ADO.NET "connection" classesregardless of the data access provider. Other properties are exposed only on the provider-specific class. For example, SqlConnection implements the PacketSize and StatisticsEnabled properties and the ClearPools method.

The Class Diagram can also be used to show property associations between classes. Let's add a SqlCommand class to the diagram and illustrate this point.

As you can see, a Class Diagram can be a helpful tool to visualize how the ADO.NET classes inherit from one another. This same technique can be used to visualize your own custom classes. Consider that the Class Diagram tool can be used to generate classes as well. I'll let you explore those features on your own. Be back here before the bus leaves for the next stop.

Deciphering the Namespaces

One of the problems you might face when trying to understand ADO.NET seems to be exacerbated by the Object Browserit does not seem to show the "real" object names for many of the objects you're likely to access in code. For example, to address the collection of DataTable objects managed by a DataSet object, you code something like the following Visual Basic .NET code (shown in Figure 8.6) that references the DataSet Tables property.

IMHO

I like to hide (for the most part) the underlying .NET Framework classes in the examples I provideI think it makes the code easier to read.

If you have a compelling reason to dig deeper into the SqlClient (or any .NET Framework DLL), you can use Reflector to expose the underlying .NET Framework implementation. While writing this book, I've found it handy to use Reflector to debug more complex .NET issues by studying what ADO.NET is doing when its objects are referenced in code.

Getting a Handle on the Class Names

So, if you started your introduction to ADO.NET by simply drilling into the Object Browser, you might think that you would have to somehow code a reference to the DataTableCollection (as shown in Figure 8.7) when you want to refer to the DataTable objects exposed by a DataSet object.

Fortunately, that's not the case, as you'll see when we tour the .NET Framework namespaces. While the DataTableCollection is a class, you don't refer to this class directly. Instead, it's referred to as the DataSet "Tables" property (which is of type DataTable), which points to a specific DataTableCollection instance. Get it? Well, if this is not yet clear, don't panic and sell your Microsoft stock. Visual Studio's Intellisense makes addressing the right object or collection of objects pretty easy. I'll revisit this issue again later in this chapter.

Using Shorthand to Address Classes

Those not familiar with .NET coding might wonder about the first line of Figure 8.8the Visual Basic .NET Imports statement (or the C# using statement). This notation tells the compiler to include this namespace when resolving class names. It does not change the application in any wayand, no, I don't know why these two languages use different terms for the same thing, since they were both created at the same time by (almost) the same company. I use the Imports or using statements to make coding easierat least, to write. Some feel that you should not use the Imports or using statements, as they hide the objects being referenced. This means when you see a class name in code, you won't know the namespace from which it's derived. For example, Figure 8.8 shows how one can reference a SqlConnection class in one of two wayseither directly or indirectly (depending on the Imports statement). You can have as many Imports (or using) statements as needed in your application. Note that the Using statement in Visual Basic .NET means something else entirelyin C#, it serves a dual purpose, but I'll get to those nuances later.

The Visual Studio Object Browser can be a handy tool when you want to explore the classes in selected namespaces or simply locate the namespace containing a class with questionable parentage. For example, if you find an example that contains a class name you can't resolve, you can use the Object Browser to search for all references to the classeven classes you define in your current project. Once you drill down into a specific class and view its functions, methods, properties, and events, you'll see a brief description of the object. In addition, you can press F1 to get object-specific help for the selected item. Of course, that assumes that the help engine is correctly wiredeven after Visual Studio 2005 shipped, the right (or meaningful) help topics don't always materialize when pressing F1.