MS的解释包括：
1、控制外部资源
IComponent 接口继承自 System.IDisposable 接口，这样可以控制对象的释放。
2、设计时支持
只要是支持IComponent接口，都可以看见一个设计器，并且拖入到这个组件中的子组件都会自动产生以下代码：
this.errorProvider1 = new System.Windows.Forms.ErrorProvider(this.components);以便加入站点。
3、承载组件
所有的子组件都是通过 IContainer 管理的，所以你的子组件都是被管理的。
事实上，很多人看见这些特性还是云里雾里，对于ISite、IContainer和IComponment的关系还是难以理解，那么我们看看这个图形。 
通过这个图，我想理解应该好一些吧。
讨论：
1、IComponent使用了注入依赖的思想；
我发现IComponent的Site属性是Get 和Set的，也就是说，IComponent实现需要有人初始化Site才能正常工作，不信的话你直接实例化一个Component对象，访问Site你会发现是Null的。
Visual Studio .NET的设计器在实例化一个IComponent对象时，会自动产生如下的代码：
this.errorProvider1 = new System.Windows.Forms.ErrorProvider(this.components);这段代码实际上就是帮助你的errorProvider1对象初始化Site属性。
另外，ISite继承了System.IServiceProvider，所以也对应的注入了服务的提供者。
关于注入依赖，请参考查找AOP和Ioc
2、.NET 2.0 增加了INestedContainer
容器一般来说，也是被另外一个IComponent持有，你也许注意到我们的设计器总是会生成这样的代码：
private System.ComponentModel.IContainer components = null; 但是这个容器对象，我们发现他并不包含 Owner 的引用，也就是说，你的子对象可以互相通讯，但是你的子对象不能访问到 他的父。
基于以上问题，.NET 2.0中增加了INestedContainer接口（继承自IContainer），他新增了Owner属性，可以访问到容器所在的所有者，即父。
3、IComponent适合的范围
我注意到，自动生成的代码中，这个组件公用一个容器，也就是说，只有整个组件释放，容器才会释放。所以当你使用一个组件时，请及时的释放这个对象。
如果你打算设计无状态的服务类，请不要使用设计器，而是需要某个子组件时，才创建，并使用容器统一管理，诸如以下的代码：
public void Save() { 
//使用容器统一管理资源。 
using (Container container = new Container()) { Component1 c1 = new Component1(container); c1.Do(); Component2 c2 = new Component2(container); c2.Do(); 
} 
}