我真的希望这不是一个愚蠢的问题,但我在某种程度上无法识别使用Caliburn.Micro将依赖关系注入视图模型的直接方法。
我有一个像这样的主壳(导体):
public class ShellViewModel : Conductor<IScreen>.Collection.OneActive, IShell
{
public ShellViewModel(IEventAggregator eventAggregator) {
ActivateItem(new DashboardViewModel());
}
}
现在我想将服务注入DashboardViewModel
,但由于ActivateItem
方法要求我传递一个实例(而不是一个类型),我强迫自己提供服务。由于ShellViewModel
并不知道底层的IoC容器,我必须将服务注入shell ...对我来说,看起来Caliburn正在尝试强制执行所有视图模型的完整图表和应用程序中的依赖项。
我知道我可以使用静态访问器来控制容器的反转,但我真的不喜欢这种方法,因为我想为我的应用程序提供一个组合根(引导程序)没有其他部分知道依赖注入等等。
答案 0 :(得分:2)
MEF [ImportMany]在构造函数中使用的参数将执行实际导入引用Hello Screens示例
在IoC静态类中,您可以使用IoC.Get<IDashBoard>()
或IoC.GetAll<IDashBoard>()
,这假设您已将类型注册到您使用的容器中。注意这个可以过度使用并导致反模式行为。我在我的一个做一个仪表板的应用程序中做了这个,在我的Container实例中用IDashBoard标记的任何东西,与实际的实现类相关联都将被拉入集合IoC.GetAll<IDashboard>()
或集合中的第一个项目基于IoC.Get<IDashBoard>()
。
您还可以让您的信息中心继承Conductor<IDashBoard>.Collection.AllActive
,允许您访问Items属性(作为Collection的一部分)并使用您的DashBoardViewMode的CTOR填充它,使用IoC.GetAll<IDashboard>()
一个地方可以获得仪表板上所需的所有物品。从那里,我查询OnActivate中的Items集合属性,并将其他viewmodels与我需要的属性相匹配,并相应地在DashBoardView上放置名为ContentControls。
这确实是从您选择的容器中拉出来的,请记住,您可能只想要容器的方法来通过其预期设计获取必要的项目。
我实际上离开了MEF,因为CM中使用的版本不适用于Open Generics并且调试缺少Export()属性开始让我疲惫不堪。