首先，我要说我要谈谈System.ComponentModel.Component。
您知道，我知道，.NET Component Model提供了（通过网站服务）定义单独的Components的能力，因此他们可以以松散耦合的方式相互通信，并且每个Component 1}}很容易更换。
但我的观点是，我可以做到这一点：
我的意思是，如果我以正确的Object Oriented Programming方式设计SW，我可以通过Abstract classes，Interfaces等方式实现所有提到的功能/互操作性。
然后为什么和 WHEN 我应该依赖于组件模型？
答案 0 :(得分：6)
好吧，你可以使用自己的基类，接口等来完成它。实际上，这正是System.ComponentModel 中的东西。它是一组通用的接口和基类，因此您可以实现组件并将其与其他人的实现一起使用。
如果您只是编写了自己的基类和接口，那么任何想要与您的代码进行交互的人都必须使用您的类。如果他们想要同时集成两个不同供应商的组件会怎么样？
特别是WinForms中的所有内容都使用System.ComponentModel来实现可以放在表单上的控件。他们必须选择某些接口来表示它，那么为什么不在System.ComponentModel中定义？为什么他们会建立自己的，当已经有一个完全精心设计的已经可用的？
答案 1 :(得分：2)
它允许您提供设计时功能，以便在例如Visual Studio。
“System.ComponentModel命名空间包含实现组件和控件的运行时和设计时行为的类型。”
您提供的功能可以是任何内容（BackgroundWorker与ComboBox做的事情截然不同，但它们都是Component。
ComponentModel提供的是元数据，而回报是您可以设计可在视觉设计器中使用的组件。因此：
public interface IDesigner : IDisposable {
IComponent Component {get;}
DesignerVerbCollection Verbs {get;}
void DoDefaultAction();
void Initialize(IComponent component);
}
命名空间还提供了TypeDescriptor / Convertor，再次可用于设计时访问属性。
（有人建议你可以使用System.ComponentModel作为一种IoC容器。我从未见过有人这样做过;正如你所说的那样，它只提供了很好的设计。）
因此：当您还想为组件提供IDesigner时，请考虑使用System.ComponentModel.Component。