Components


A component is a subprogram or part of a program designed to be used by other programs. In addition, a component is a binary unit (executable code as opposed to source code) that can be used by other programs without having to recompile either the source code of the component itself or the program using the component. This means that third-party suppliers don't have to provide the source code for their components.

In the loosest sense, a component includes any binary subprogram; thus, any DLL is by definition a component, since it is a subprogram containing executable code.

A stricter definition of a component requires it to provide a means of advertising its contents to other programs. Assemblies provide this advertising ability within .NET.

In strictest definition of a component in the .NET Framework, a component must implement the the System.ComponentModel.IComponent interface, which includes methods that can be called by other components to release no-longer-used system resources and to support integration with design tools.

To aid your understanding of the benefits of assemblies, this chapter uses the less strict definition, including the requirement of advertising the contents of the component.

Benefits of Components

Components provide improved reusability, flexibility, and delivery of subprograms. In addition, binary reuse saves time and increases reliability.

For example, consider a class named Shapes that contains objects for representing circles, triangles, or other shapes. It might contain methods for calculating the area of a shape or performing other operations with shapes. Many kinds of programs might use a Shapes class: painting/drawing programs, engineering, architecture/building design, computer-aided design, games, and others.

Wouldn't it be great if the routines for drawing and manipulating shapes could be defined just once and reused by all these programs? This is the reusability benefit.

What if this reuse could be accomplished without having to recompile and link the Shapes class library for every program that uses it? This saves time and helps reliability, since it removes the possibility of introducing problems each time you compile and link.

Even better, maybe some other person or company has already written a shapes component that does what you want, then you can use the component (by downloading and/or purchasing it) without having to write it yourself. If you could share components at the binary level, you wouldn't have to worry about what programming language was used to develop the component. the .NET Framework and assemblies provide all of these benefits.

A Brief History of Components

For different programs to reuse components at the binary level, there must be some standard for implementing the way classes and objects are named and used at the binary level. The standard for doing this in Microsoft-based products has evolved over time.

Microsoft Windows introduced the DLL (Dynamic Link Library) where one or more programs could use a chunk of code stored in a separate file. This worked at a very basic level if the programs were written in the same language (typically C). However, programs needed to know a lot in advance about the DLLs they used, and DLLs did not enable programs to use one another's data.

To exchange data, DDE (Dynamic Data Exchange) was developed. This defined a format and mechanism for piping data from one program to another, but was not flexible. OLE 1.0 (Object Linking and Embedding) followed, which enabled a document such as a Word document to actually contain a document from another program (such as Excel). This was something like components, but OLE 1.0 was not truly a general-purpose component standard.

Microsoft defined its first true component standard with the COM (Component Object Model) standard implemented in Windows in the mid-1990s. OLE version 2 and many successor technologies were built on COM. DCOM (Distributed COM) introduced the ability for COM components to interact over a network, and COM+ added services that components could call on to ensure high performance in multitier environments.

COM works well but is difficult to learn (especially when used from C++) and to use. COM requires information about components to be inserted into the Windows system Registry, making installation more complex and component removal more difficult.

COM was originally designed for use with C/C++; it was enhanced so that Visual Basic could use it (Automation) and indeed this works well, but it became even harder for the C/C++ programmer to make components compatible with Visual Basic (you still could not inherit from a class defined in another language, for example).

Additionally, as users installed multiple versions of DLLs and COM components from Microsoft and other companies over time, problems arose with programs using different versions of the same shared DLL. It was very easy for one program to install a different version of a DLL already used by another program, and this would cause the original program to break (this phenomenon was the infamous DLL hell). The burden of tracking all the information about the different DLLs installed on a system made it very hard to upgrade and maintain components.

the .NET programming model brings a new standard that addresses these problems, the .NET assembly.




Beginning Visual C# 2005
Beginning Visual C#supAND#174;/sup 2005
ISBN: B000N7ETVG
EAN: N/A
Year: 2005
Pages: 278

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net