【问题标题】:should I store a reference to the parent viewmodel in the child viewmodel?我应该在子视图模型中存储对父视图模型的引用吗?
【发布时间】:2013-03-14 21:16:00
【问题描述】:

那么,如果我将父 ViewModel 的引用存储在子 ViewModel 中,那会是犯罪吗?我会违反 MVVM 规则吗?我的子视图是一个带有上下文菜单的窗口。选择适当的菜单项时,需要创建新的子视图。父级仅负责创建子视图。所以保持对父视图模型的引用对我有很多好处。同时我不想破坏模式规则。

class MainViewModel
{
    List<ChildViewModel> _childrenViewModels = new List<ChildViewModel>();

    public AddChild(ChildViewModel childViewModel)
    {
        _childrenViewModels.Add(childViewModel);
        childViewModel.Owner = this;
    }
}

class ChildViewModel
{
    private Child _child;
    public MainViewModel Owner { get; set; }

    public ChildViewModel(Child child)
    {
        _child = child;
    }
}

【问题讨论】:

  • 这些模式只是帮助您入门的指南;不再。只有当你发现自己偏离了模式,你才应该四处看看,看看你是否选择了错误的模式。
  • 模式并不是为了创建架构,而是为了解决架构中可能出现的问题。确保业务目标和完整性的最简单方法是正确的方法。
  • So if I store the parent ViewModel's reference in the child ViewModel will that be a crime - 绝对没有。谁告诉你的?任何 ViewModel 都可以引用任何其他 ViewModel(只要它不包含对 UI 元素的引用),这是完全可以的。 MVVM 的想法是将表现与行为分开,而不是创建很多限制来阻止您编写干净的代码。
  • HighCore 说得很好。
  • 注意循环依赖——显然,如果你在进行构造函数注入和单元测试,你可能会发现 A 依赖于 B 而 B 依赖于 A,这可能是代码异味。我并不是说不要对父母保留参考,但应该有一个理由 - 这里的原因是什么?不能使用冒泡事件/动作或事件聚合器模式吗?

标签: c# .net wpf mvvm


【解决方案1】:

没有。一般来说,如果你多次使用这种技术,试着把它隐藏在抽象后面,事实上这就是著名的Caliburn.Micro [I love it] 项目用它的IChild interface 所做的。

【讨论】:

    【解决方案2】:

    答案是否定的,但出于您的目的,如果父级所做的只是创建子视图模型,为什么还需要此参考。建立这种联系的目的是什么?

    【讨论】:

    • 我需要参考,因为当用户从子视图的上下文菜单中选择特定菜单项时,它应该创建一个新窗口。现在我想把它留给父(主)视图来创建子视图和窗口。但是事件发生在子视图中。也许我们也可以做事件路由?不知道,WPF这么大,看了多少书都记不住了。因此,我正在研究这个项目以真正弄清楚。
    【解决方案3】:

    虽然这种模式根本不是犯罪或“代码异味”,但在许多情况下,以接口实现者的形式而不是作为其自己的类传递对父级的引用可能会更好。因此,接口中只定义了子类需要在父类中访问的属性或方法,而子类没有访问父类的其他公共方法或属性的权限,如果使用不当可能会导致错误。这可能涉及更多代码,但类之间更松散的连接可能会带来好处。如果仅此而已,它有助于使孩子和父母之间的联系更加自我记录,并且让阅读代码的人更容易理解。

    【讨论】:

      猜你喜欢
      • 2023-04-03
      • 2013-05-07
      • 2012-08-25
      • 2017-05-04
      • 1970-01-01
      • 2018-06-24
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多