首先,我要说的是,我将谈论System.ComponentModel.Component。
您知道,我理解,.NET Component Model提供了定义单独Components的能力(通过站点服务),因此它们可以以松散耦合的方式相互通信,而且每个Component都很容易替换。
但我的意思是,如果我以正确的Object Oriented Programming方式设计SW,我可以通过Abstract classes、Interfaces等实现所有提到的功能/互操作性。
那么为什么是和,而应该依赖于组件模型呢?
发布于 2010-03-19 10:31:20
那么,您可以使用您自己的基类、接口等等来完成这个任务。事实上,这正是System.ComponentModel中的内容。它是一组通用的接口和基类,因此您可以实现组件,并将它们与其他人的实现一起使用。
如果您只是创建了您自己的基类和接口,那么任何想要与您的代码进行接口的人都必须使用您的类。如果他们想同时集成两个不同供应商的组件呢?
特别是,WinForms中的所有内容都使用System.ComponentModel组件来实现您可以放在表单上的控件。他们必须选择一些接口来表示这一点,那么为什么不使用System.ComponentModel中定义的接口呢?既然已经有了完美的设计,他们为什么要建造自己的呢?
发布于 2012-11-09 12:23:06
它允许您提供用于例如Visual的设计时功能。
“System.ComponentModel命名空间包含实现组件和控件的运行时和设计时行为的类型。”您提供的功能可以是任何功能(BackgroundWorker做了与ComboBox非常不同的事情,但它们都是Component)。
ComponentModel提供的是元数据,其好处是您可以设计可以在视觉设计器中使用的组件。因此:
public interface IDesigner : IDisposable {
IComponent Component {get;}
DesignerVerbCollection Verbs {get;}
void DoDefaultAction();
void Initialize(IComponent component);
}命名空间还提供了TypeDescriptor /转换器的内容,同样可以用于对属性的设计时访问。
(有人建议您可以使用System.ComponentModel作为IoC容器。我从来没有见过有人这样做;正如你说的,因为它提供的只是一个好的设计)。
因此:当您还想在组件中提供一个System.ComponentModel.Component时,请考虑使用IDesigner。
https://stackoverflow.com/questions/2476433
复制相似问题