views:

38

answers:

1

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?

+3  A: 

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?

Dean Harding