.NET Component Model explanation

Question

First of all, I have to say that I'm going to talk about System.ComponentModel.Component.

You know, I understand, that the .NET Component Model provides ability (through Site Services) to define separate Components, so they can communicate with each other in a loosely coupled way, and that each Component is easily replaceable.

But my point is, that I can achieve this otherwise: I mean if I design the SW in the right Object Oriented Programming manner, I can by means of Abstract classes, Interfaces etc. achieve all mentioned functionality / interoperability.

Then WHY and WHEN should I rely on the Component Model?

Answer 1

Well, you can do it with your own base classes, interfaces and so on. In fact, that's exactly what the stuff in System.ComponentModel is. It's a common set of interfaces and base classes so that you can implement your components and use them with other people's implementations.

If you just made up your own base classes and interfaces, then anybody who wanted to interface with your code would have to use your classes. And what if they wanted to integrate with two different vendor's components at once?

In particular all of the stuff in WinForms uses the System.ComponentModel stuff to implement controls that you can put on your form. They had to choose some interface to represent that, so why not the one defined in System.ComponentModel? Why would they build their own, when there's already a perfectly well-designed one already available?

Answer 2

It lets you provide Design-Time capability for use in e.g. Visual Studio.

"The System.ComponentModel namespaces contain types that implement the run-time and design-time behavior of components and controls." The functionality you provide could be anything (BackgroundWorker does something very different to a ComboBox yet they are both a Component).

What the ComponentModel provides is metadata and the payoff is that you can design components that can be used in the visual designer. Hence:

public interface IDesigner : IDisposable {

        IComponent Component {get;}        
        DesignerVerbCollection Verbs {get;}
        void DoDefaultAction();
        void Initialize(IComponent component);
}

The namespace also provides the TypeDescriptor / Convertor stuff, again usable for design-time access to properties.

(It has been suggested that you could use System.ComponentModel as a kind of IoC container. I've never seen anyone do this; as you say, for that it offers nothing over just good design).

So: consider using System.ComponentModel.Component when you are also want to provide a IDesigner with your component.

• http://msdn.microsoft.com/en-us/library/ms973820.aspx
• http://msdn.microsoft.com/en-us/library/system.componentmodel.design.aspx