10

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

要成为一个组件，一个类必须实现 IComponent 接口并提供一个基本构造函数，该构造函数不需要参数或 IContainer 类型的单个参数。

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

  • 服务定位器

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

  • 通过属性进行依赖注入

    通过属性注入依赖项。如果需要在设计器中显示组件，请提供默认实例。记录需要注入哪些属性。

  • 使用 Initialize 方法注入依赖项

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

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

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

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

4

1 回答 1

7

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

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

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

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

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

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

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

于 2009-07-02T19:40:34.080 回答