Question

我目前有一个类似于

的层次结构

MainWindowViewModel
    TabViewModel
        EditorViewModel
            ReviewingServices
                ConflictFinder

我遇到的问题是TabViewModel希望收到有关冲突（来自ReviewingServices）以及其他内容的通知。我可以为我的所有依赖项创建公共getter，并使用DependencyA.DependencyB.DependencyC += SomeHandler;订阅我想要的任何东西，但这相当混乱。我发现自己创造了太多我想要计算的事件。从本质上讲，我创建了一个混乱的事件网络。我喜欢我为每个班级创造的责任分离，但是当每个班级每个班级有2-3个事件时，它们很难维护。如果用户只有1级以上，我就没有问题创建和维护事件。当MainWindowViewModel希望收到有关新评论的通知时（ReviewingServies发布），就会出现混乱。

在订阅者想要订阅深度嵌套在应用程序中的事件时，是否更好地执行这些类型的事件？

Answer 1

我不知道我是否真的遇到了麻烦，但我建议看看某种事件聚合器。试着查看Caliburn one，但是自己实现一个并不是那么不同。通过这个，您可以使用类型命名事件，并从任何地方订阅它。

Answer 2

尝试使用Microsoft Prism及其Event Aggregator

Answer 3

链接DependencyA.DependencyB.DependencyC通常被视为违反Law of Demeter（您实际上依赖于依赖项的依赖关系等）。

我最近通过使用由IMyOperationNameContext等接口定义的Mediator解决了类似的设计问题，这允许我将两个ViewModel的组合上下文共享/注入到WinForms控件中，该控件使用第三个ViewModel以及所有这些都没有直接将三个模型耦合在一起。

这样的事情（注意样本中IAlbumContext如何更多地充当代理，但这仅仅是因为样本被简化了）：

interface IAlbumContext
{
    public AlbumInfo SelectedAlbum { get; set; }
}

class AlbumContext
{
    AlbumSelectionViewModel _model;

    public AlbumContext(AlbumSelectionViewModel model)
    {
        _model = model;
    }     

    public Album SelectedAlbum {
        get { return _model.Album; }
    }
}

class PhotoUploadDialog : Dialog
{
    public PhotoUploadDialog(IAlbumContext context, PhotoUploadViewModel viewModel)
    {
    }
}

虽然这个解决方案对我有用，但我喜欢它具有很高的内聚力和解耦性，但它最终不具有大规模的可扩展性（例如，这些上下文接口的数量可以根据应用程序快速增长）。然而，通过更通用的解决方案，权衡是代码变得更难以遵循。

MVVM备用事件模式

3 个答案: