将 Castle.Windsor 与 Windows 窗体应用程序结合使用

Question

到目前为止，我一直在使用 ASP.NET MVC 学习 Castle.Windsor 的 IoC/DI，但我有一个在 Windows 窗体中完成的副项目，我想知道是否有一种有效的方法来使用它那。

我的问题在于表单、服务等的创建。在 ASP.NET MVC 中，有一种“激活器”在幕后执行此操作，但 Windows 窗体中并非如此。我必须创建一个像 var form = new fclsMain(); 这样的新表单，所以像 .. 这样的表单

class fclsMain : System.Windows.Forms.Form
{
 private readonly ISomeRepository<SomeClass> someRepository;
 fclsMain(ISomeRepository<SomeClass> someRepository)
 {
  this.someRepository = someRepository;
 }
}

有点不足。我基本上必须做...

var form = new fclsMain(IoC.Resolve);

正如我在至少三个问题中指出的那样，这并不明智，因为这被认为不是 IoC 的“正确”用法。

那么如何使用 Castle.Windsor 和 Windows 窗体呢？有什么方法可以设计表单激活器之类的吗？我真的很迷失，如果我不能制作一个可以解析的静态 IoC 容器，我该怎么办？

Answer 1

在这里你正在做一些不太“依赖注入”的事情......

var form = new fclsMain(IoC.Resolve<ISomeRepository<SomeClass>);

“新”是问题......
您必须调用

var form = IoC.Resolve<fcls>();

fcls 类型的表单，必须通过 Fluent Registration API 正确配置 o

Answer 2

为了在整个应用程序中使用相同的 Castle 容器，请创建一个静态类，例如：

public static class CastleContainer {
    private static IWindsorContainer container;

    public static IWindsorContainer Instance {
        get {
            if (container == null) {
                container = new WindsorContainer();
            }
            return container;
        }
        // exposing a setter alleviates some common component testing problems
        set { container = value; }
    }

    // shortcut to make your life easier :)
    public static T Resolve<T>() {
        return Instance.Resolve<T>();
    }

    public static void Dispose() {
        if (container != null) 
            container.Dispose();
        container = null;
    }
}

然后在 Main() 方法中注册/安装所有组件。您还可以挂钩应用程序关闭事件来调用 Dispose()（尽管这并不重要）。

Castle 实际上在其快速入门指南中使用了 Windows 窗体应用程序。

编辑：

我上面显示的模式是服务定位器的变体，有些人将其称为反模式。它名声不好，除其他原因外，还因为它引用了 Windsor 来充实你的代码库。理想情况下，您应该只调用一次 container.Resolve<...>() 来创建根表单。所有其他服务和表单通过构造函数注入。

实际上，您可能需要再调用几次 Resolve，特别是如果您不想在启动时加载应用程序的每个角落。在 Web 世界中，最佳实践是将容器交给 Web 框架。在 Windows 窗体世界中，您需要实现自己的服务定位器，如上所述。 （是的，将容器交给ASP.NET MVC框架仍然是服务定位器模式）。

我编辑了上面的代码示例，以便静态容器是可注入的；没有资源被束缚在静态上下文中。如果您最终创建了自己的服务定位器，您可能还需要创建一个像这样的测试实用程序以使测试更容易。

public static class TestUtilities 
{
    public static IContainer CreateContainer(Action<IContainer> extraConfig = null) 
    {
        var container = new WindsorContainer();
        // 1. Setup common mocks to override prod configuration
        // 2. Setup specific mocks, when provided
        if (extraConfig != null)
            extraConfig(container);
        // 3. Configure container with production installers
        CastleContainer.Instance = container;
        return container;
    }
}

这为创建新容器提供了一条捷径，该容器看起来很像生产版本，但某些服务被替换为模拟。一些示例测试可能如下所示：

[Test]
public void SubComponentWorksGreat() 
{
    using (var container = TestUtilities.CreateContainer())
    {
        var subComponent = container.Resolve<SubComponent>();
        // test it...
    }
}

[Test]
public void SubComponentWorksGreatWithMocks() 
{
    var repoMock = new Mock<IRepository>();
    using (var container = TestUtilities.CreateContainer(c => 
            c.Register(Component.For<IRepository>().Instance(repoMock.Object))))
    {
        var subComponent = container.Resolve<SubComponent>();
        // test it with all IRepository instances mocked...
    }
}

最后一点。为每个测试创建一个完整的容器可能会非常昂贵。另一种选择是创建完整的容器，但仅使用嵌套容器进行实际测试。

Answer 3

正如您所说，您不必“必须”新建表格。
我使用 WinForms 并且从不调用“new FormName()”。它本身始终是一种依赖。否则我必须在构造函数中填充服务定位器调用。

我可能会使用 ServiceLocator（如另一个答案中所示）但仅在最顶层。
例如，我实现了一个命令模式来拦截工具栏按钮。
看起来像这样：

public void Handle(string commandName)
{
    var command = IoC.Resolve<ICommand>(RegisteredCommands[commandName]);
    command.Execute();
}

然后，在简化的情况下，这是在其他地方编写的代码：

public class ShowOptionsCommand : Command, ICommand
{
    private readonly IOptionsView _optionsView;

    public ShowOptionsCommand(IOptionsView optionsView)
    {
        _optionsView = optionsView;
    }

    public void Execute()
    {
        _optionsView.Show();
    }
}

是的，我使用“服务定位器”，但您几乎不会看到它。
这对我来说很重要，因为在整个代码中（例如在每个类中）调用服务定位器会破坏使用控制和依赖反转的一些要点。需要额外的工作才能进行测试等