Working with the SQL Server Base Class Library

The .NET Framework provides a number of classes, interfaces, and value types tailored to SQL Server that allow you to build functionality and develop solid applications and services. The remainder of this chapter will be devoted to a brief description of the class library hierarchy that is accessible from your development environment.

To facilitate interoperability, the .NET classes and types are compliant with the CLS. Any language compiler that targets the CLR can thus use them. However, as mentioned earlier all compilers do not equally support the class libraries.

The .NET Framework classes provide an extensive array of functionality related to basic I/O, threading, networking, security, data access, forms, Web services, and so on. You can use the classes and data types to build sophisticated applications and services, and components or controls that can be simply plugged into any .NET-compliant environment. Later chapters throughout this book delve into advanced use of the class libraries for stored procedures, triggers, functions, and the like.

You can derive from the .NET classes or extend functionality where permitted, or else you can implement an interface directly in your code from a runtime-based class that implements an interface.

The .NET Framework types are named using dot notation that denotes a hierarchy or a namespace. This is not unlike the naming notation used by Java, or the namespaces notation used by the Internet Domain Name System or the Active Directory namespace. For example, the System.Data.ADO namespace refers to the hierarchy of classes that represent the functionality of the ActiveX Data Object technology (as well as CLR database objects for SQL Server 2005). In order to gain access to the ADO in .NET, you would need to reference System.Data.ADO to directly reference the actual ADO class, which is the last name in the namespace “chain” of classes. If you were to reference system.data, you would not only reference ADO but also all other classes on the system.data namespace. If you do not need any other data class in your application, you would be wasting a lot of resources compiling in the other resources on the data namespace, such as the SQL types.

The dot notation syntax has no effect on the visibility and access characteristics of classes and their members. It also has no influence on inheritance or binding or the interfaces available. In fact, the namespaces can also be partitioned across assemblies, and a single assembly may contain multiple class namespaces.

It really doesn’t take long to understand the nuances of the CLR and its various components. In fact, most of the developers on your team writing code targeting the CLR need never really worry about the CLR at all. Instead, you can elect one or two people to be CLR “diligent.”

CLR specifics-especially the GC, application domains, and security-need to be hashed out in the design and modeling stage. Provide specific support for exception handling (by delegating the duty of adding security exceptions to your custom exception classes), and not only will projects come in ahead of schedule, but you can take Fridays off to go sailing or horseback riding.