使用Caliburn Micro将EventAggregator注入ViewModel

从EventAggregator上的Caliburn Micro文档中提取：

// Creating the EventAggregator as a singleton.
public class Bootstrapper : BootstrapperBase {
    private readonly SimpleContainer _container =
        new SimpleContainer();
     // ... Other Bootstrapper Config
    protected override void Configure(){
        _container.Singleton<IEventAggregator, EventAggregator>();
    }
    // ... Other Bootstrapper Config
}
// Acquiring the EventAggregator in a viewModel.
public class FooViewModel {
    private readonly IEventAggregator _eventAggregator;
    public FooViewModel(IEventAggregator eventAggregator) {
        _eventAggregator = eventAggregator;
    }
}

所以问题是如何让Bootstrapper创建的EA实例注入到您的VM中？

var svm = new SomeViewModel(?);

我试着用Caliburn.Micro.IoC.Get方法，但没用。。。

不，您不使用var svm = new SomeViewModel(?)，也不使用IoC.Get，因为服务位置正在成为一种反模式
文章作者建议的模式是最佳实践，即应该通过构造函数注入将依赖项注入到需要它们的对象
我不知道如何用其他方式来表达它，但让你的应用程序可组合，并为你创建一个体系结构表示层
我会查看Screens，Conductors and Composition这篇文章，因为它有一些与我所说的相关的好想法，并且它附带的应用程序是一个很好的想法
我也会读到关于依赖注入的文章。

我写了您引用的文章。Sniffer是正确的（请留下绿色勾号）。Caliburn.Micro在一个名为composition的概念上投入了大量资金。这意味着整个对象图是在运行时隐式构建的，或者是组合的，如果你愿意的话。

这个想法是，你的"shell"ViewModel是由引导程序创建的，shell反过来创建其他ViewModel，依此类推。这允许使用构造函数注入，并提供最佳的可组合性。

然而，有时这不是所需的功能，为此，我们确实通过IoC类提供了一个服务定位器；然而，正如Sniffer所说，大多数服务位置的用例都被认为是反模式的，因此应该严格审查它的使用情况，否则它会在路上咬你的屁股。

我正在为IoC和我们内置的依赖容器SimpleContainer的两篇新文章做最后的润色，一旦这些文章完成，我将添加到EventAggregator文档的相关链接，它应该提供更多关于注入站点和最佳实践的上下文。

相关内容

最新更新

热门标签：