.net - 如何将可设计组件与依赖注入(inject)相结合

Question

创建可设计的 .NET 组件时，您需要提供默认构造函数。来自 IComponent文档:

To be a component, a class must implement the IComponent interface and provide a basic constructor that requires no parameters or a single parameter of type IContainer.

这使得无法通过构造函数参数进行依赖注入(inject)。 (可以提供额外的构造函数，但设计者会忽略它们。)我们正在考虑的一些替代方案:

服务定位器

不要使用依赖注入(inject)，而是使用服务定位器模式来获取依赖项。这似乎是什么 IComponent.Site。 GetService是为了。我想我们可以创建一个可重用的 ISite 实现(ConfigurableServiceLocator？)，它可以配置必要的依赖项。但是这在设计师的环境中是如何工作的呢？

通过属性进行依赖注入(inject)

通过属性注入(inject)依赖项。
提供默认实例(如果是)
有必要在一个组件中显示
设计师。记录哪些属性
需要注入(inject)。

使用 Initialize 方法注入(inject)依赖项

这很像通过属性注入(inject)，但它将需要注入(inject)的依赖项列表保存在一个地方。这样，所需依赖项的列表就会被隐式记录，当列表发生变化时，编译器会帮助你解决错误。

知道这里的最佳做法是什么吗？你怎么做呢？

编辑 :我已删除“(例如 WinForms UserControl)”，因为我打算将问题与一般组件有关。组件都是关于控制反转的(参见 UMLv2 specification 的第 8.3.1 节)，所以我不认为“你不应该注入(inject)任何服务”是一个好的答案。

编辑 2 :花了一些时间使用 WPF 和 MVVM 模式最终“得到”马克的答案。我现在看到视觉控制确实是一个特例。至于在设计器表面上使用非可视组件，我认为 .NET 组件模型从根本上与依赖注入(inject)不兼容。它似乎是围绕服务定位器模式设计的。也许这将随着 .NET 4.0 中添加的基础设施而开始改变 System.ComponentModel.Composition命名空间。

Answer 1

同样的问题困扰了我很长时间，直到我意识到我以错误的方式思考它。 AFAIR，创建 IComponent 实现的唯一原因是提供设计时功能 - IComponent 实现没有运行时效果。

由此推论，这意味着您应该主要创建组件来实现设计时功能。特别是对于控件，这意味着您可以将组件配置为以某种方式运行。意识到这与组件的实际行为方式或它显示的数据完全不同，这一点非常重要。它不应该在设计时有行为，也不应该包含数据。

因此，对构造函数的约束实际上是一种祝福，因为它指导您重新考虑您的设计。控件是一种与数据源无关的软件，它以某种方式显示数据并与数据交互。只要该数据符合某些接口(interface)等，Control 就会很高兴。数据如何到达与控制无关，也不应该如此。让 Control 控制如何加载和修改数据是错误的。

在 WPF 中，这比在 Windows 窗体中明确得多:您为特定控件提供 DataContext 并将控件的属性绑定(bind)到该 DataContext 的成员。 DataContext(可以是任何对象)源自 Control 外部；那是您的责任或您的表示层。

在 Windows 窗体中，您仍然可以通过将数据上下文分配给控件来执行相同的操作。本质上，这是属性注入(inject) - 请注意您不应该注入(inject)服务；你应该注入(inject)数据。

总之，我不会接受你的任何建议。相反，让控件具有一个或多个属性，允许您将数据分配给控件，并使用数据绑定(bind)来绑定(bind)此数据。在控件的实现中，准备好处理没有数据的情况:每次控件在设计时由 VS 托管时都会发生这种情况。 Null Object 模式对于实现这种弹性非常有用。

然后，从 Controller 设置数据上下文。这就是 MVC 的做法:Control 是 View，但您应该有一个单独的 Controller，可以实例化 Model 并将其分配给 View。