Programming .NET Components, 2nd Edition

.NET Adherence to Component Principles

One challenge facing the software industry today is the skill gap between what developers should know and what they do know. Even if you have formal training in computer science, you may lack effective component-oriented design skills, which are primarily acquired through experience. Today’s aggressive deadlines, tight budgets, and a continuing shortage of developers precludes, for many, the opportunity to attend formal training sessions or to receive effective on-the-job training. Nowhere is the skill gap more apparent than among developers at companies who attempt to adhere to component development principles. In contrast, object-oriented concepts are easier to understand and apply, partly because they have been around much longer (and hence a larger number of developers are familiar with them) and partly because of the added degree of complexity involved with component development as compared to development of monolithic applications.

.NET Versus COM

If you’re a seasoned COM developer, .NET might seem to be missing many of the elements you have taken for granted as part of your component development environment. If you have no COM background, you can skip this sidebar. If you are still reading, you should know that the seemingly missing elements remain in .NET, although they are expressed differently:

• There is no base interface, such as IUnknown, from which all components derive. Instead, all components derive from the class System.Object . Every .NET object is therefore polymorphic with System.Object.

• There are no class factories. In .NET, the runtime resolves a type declaration to the assembly containing it and the exact class or struct within the assembly. Chapter 2 discusses this mechanism.

• There are no Interface Definition Language (IDL) files or type libraries to describe your interfaces and custom types. Instead, you put those definitions in your source code. The compiler is responsible for embedding the type definitions in a special format in your assembly, called metadata . Metadata is described in Chapter 2.

• Component dependencies are captured by the compiler during compilation and persisted in a special format in your assembly, called a manifest. The manifest is described in Chapter 2.

• There is no reference counting of objects. .NET has a sophisticated garbage-collection mechanism that detects when an object is no longer being used by clients and then destroys it. Chapter 4 describes the .NET garbage-collection mechanism and the various ways you can manage resources held by objects.

• Identification isn’t based on globally unique identifiers (GUIDs). Uniqueness of type (class or interface) is provided by scoping the types with the namespace and assembly name. When an assembly is shared between clients, the assembly must contain a strong name— i.e., a unique digital signature generated by using an encryption key. The strong name also guarantees component authenticity, and .NET refuses to execute a mismatch. In essence, these are GUIDs, but you don’t have to manage them any more. Chapter 5 discusses shared assemblies and strong names.

• There are no apartments. By default, every .NET component executes in a free-threaded environment, and it’s up to you to synchronize access. Synchronization can be done either by using manual synchronization locks or by relying on automatic .NET synchronization domains. .NET multithreading and synchronization are discussed in Chapter 8.

A primary goal of the .NET platform is to simplify the development and use of binary components and to make component-oriented programming more accessible. As a result, .NET doesn’t enforce some core principles of component-oriented programming, such as separation of interface from implementation, and unlike COM, .NET allows binary inheritance of implementation. .NET enforces a few of the core concepts and merely enables the rest. Doing so caters to both ends of the skill spectrum. If you understand only object-oriented concepts, you will develop .NET “objects,” but because every .NET class is consumed as a binary component by its clients, you can still gain many of the benefits of component-oriented programming. If, on the other hand, you understand and master how to apply component-oriented principles, you can fully maximize the benefits of .NET as a powerful component-development technology.

This duality can be confusing. Throughout the book, whenever applicable, I will point out the places where .NET doesn’t enforce a core principle and suggest methods to stick with it nonetheless.