在wpf

时间:2015-10-28 09:01:43

标签: c# wpf

我目前正在创建一个"向导"在我的程序中创建新项目。我有一个几乎已经完成的解决方案,但它没有感觉到#14;正确"并开始考虑其他解决方案。也许应该注意我也使用MVVMLight。

我目前的解决方案:

  • 我有一个窗口,窗口包含自定义用户控件(它们代表向导的每个页面)。

  • 窗口和用户控件共享相同的视图模型

  • 当您单击后退/下一步时,视图模型会处理应该显示的用户控件

这个问题是我不喜欢共享视图模型。我有一个共享的视图模型,因为所有页面在同一个对象上配置不同的东西,并且它更容易遵循。但与此同时,thew视图模型包含许多每个单独用户控制不需要的东西(例如,只有一个页面需要添加/编辑过滤器的方法)。如果我将它们用于除向导之外的其他内容,它还会使以后重新用户控制变得困难。

那么我应该为窗口创建不同的视图模型,并且每个用户控制并使用MVVMLights MessengerInstance在视图模型之间发送消息?我觉得它更干净但是作为一个读者,它可能更难以遵循(当我发送信息时我感觉到的一般情况)?

使用messenger这将是一个像这样的工作流程:

  1. 用户输入"页面上的所有信息"
  2. 用户点击下一个(属于该窗口)
  3. Windows视图模型必须向用户控件发送消息以检查所有数据是否有效
  4. 用户控制检查数据,如果数据有效则必须发回。如果它有效则告诉下一页显示,如果没有显示错误消息。
  5. 因此,我不需要使用共享视图模型解决方案来回传递大量消息。

    或者我有更好的解决方案吗?

1 个答案:

答案 0 :(得分:0)

我希望你在这里得到的答案主要是基于意见的,但无论如何都要进行。

目前,您的视图模型有多个责任,因此需要更改一个以上的原因。将您的视图模型拆分为更小,更易于管理的类当然是个好主意。这可能会降低可读性,但我不同意。确保课程只有一个职责的想法可以使事情变得简单并促进重复使用。

话虽这么说,您的视图模型很可能会引用许多其他视图模型,但这不是“事实上,世界末日是一件好事。视图模型之间的父子关系非常类似于视图中的父子关系。例如,Window包含许多UserControls,模仿与视图模型的关系并没有错。

现在,有几种方法可以在视图模型之间进行通信。我个人更喜欢使用事件,其中子视图模型引发父视图模型订阅的事件。很简单,真的。虽然在这种情况下存在一定程度的耦合,但您当然可以将类抽象为接口并使用依赖注入将它们注入父视图模型。使用事件取决于个人偏好,但是MVVMLight有一个非常好的MessengerInstance,可以进一步分离视图模型。

因此。我的建议是:

  • 制定视图模型的职责
  • 将大量视图模型拆分为较小的视图模型(基于职责)。
  • 在视图模型之间创建父子关系。事实上,您的观点将指出您在关系方面的正确方向。