10

首先，我不得不说，我要谈谈System.ComponentModel.Component.

你知道，我理解，.NET Component Model提供了定义分离的能力（通过站点服务）Components，因此它们可以以松散耦合的方式相互通信，并且每个Component都可以轻松替换。

但我的观点是，我可以通过其他方式实现这一点：我的意思是，如果我以正确的Object Oriented Programming方式设计软件，我可以通过Abstract classes等Interfaces方式实现所有提到的功能/互操作性。

那么为什么以及何时应该依赖组件模型？

4

2 回答 2

8

好吧，您可以使用自己的基类、接口等来完成。事实上，这正是 System.ComponentModel中的内容。它是一组通用的接口和基类，因此您可以实现您的组件并将它们与其他人的实现一起使用。

如果您只是构建自己的基类和接口，那么任何想要与您的代码交互的人都必须使用您的类。如果他们想同时与两个不同供应商的组件集成怎么办？

特别是 WinForms 中的所有东西都使用 System.ComponentModel 东西来实现可以放在表单上的控件。他们必须选择一些接口来表示它，那么为什么不使用 System.ComponentModel 中定义的接口呢？既然已经有一个设计完美的，他们为什么要自己建造呢？

于 2010-03-19T10:31:20.703 回答
3

它允许您提供设计时功能，以便在例如 Visual Studio 中使用。

“System.ComponentModel命名空间包含实现组件和控件的运行时和设计时行为的类型。” 您提供的功能可以是任何东西（BackgroundWorker与 a 有很大不同ComboBox但它们都是 a Component）。

提供的ComponentModel是元数据，而回报是您可以设计可在视觉设计器中使用的组件。因此：

public interface IDesigner : IDisposable {

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

命名空间还提供了 TypeDescriptor / Convertor 的东西，同样可用于设计时对属性的访问。

（有人建议您可以使用 System.ComponentModel 作为一种 IoC 容器。我从未见过有人这样做；正如您所说，因为它提供的只是好的设计）。

所以：考虑使用 System.ComponentModel.Component 当您还想为IDesigner您的组件提供一个。

于 2012-11-09T12:23:06.630 回答