Programming .NET Components, 2nd Edition

Basic Terminology

The term component is probably one of the most overloaded and therefore most confusing terms in modern software engineering, and the .NET documentation has its fair share of inconsistency in its handling of this concept. The confusion arises in deciding where to draw the line between a class that implements some logic, the physical entity that contains it (typically a dynamic link library, or DLL), and the associated logic used to deploy and use it, including type information, security policy, and versioning information (called an assembly in .NET). In this book, a component is a .NET class. For example, this is a .NET component:

    public class MyClass
    {
       public string GetMessage()
       {
          return "Hello";
       }
    }

Chapter 2 discusses DLLs and assemblies and explains the rationale behind physical and logical packaging. It also discusses why it is that every .NET class, unlike traditional object-oriented classes, is a binary component.

A component is responsible for exposing business logic to clients. A client is any entity that uses the component, although typically, clients are simply other classes. The client’s code can be packaged in the same physical unit as the component, in the same logical unit but in a separate physical unit, or in separate physical and logical units altogether. The client code should not have to make any assumptions about such details. An object is an instance of a component, a definition that is similar to the classic object-oriented definition of an ...