用于复杂应用程序的WPF MVVM

本文关键字:WPF MVVM 应用程序 复杂 用于 | 更新日期: 2023-09-27 18:20:44

我正处于具有复杂需求的WPF应用程序的设计阶段:我必须通过代码控制视图,因为我必须根据用户权限启用、禁用或隐藏元素。此外,在TreeView中,我必须根据项目类型(内部逻辑)和用户权限的依赖性来控制TreeViewItems的ContextMenu。要显示的数据由存储过程加载到数据集(多个表)。MVVM和维护(与直接代码隐藏相比,MVVM的代码复杂性)以及控件可见性的所有稳定性有何经验。

不需要自动测试,因为可见部分必须始终包含在测试中(控件的可见性取决于加载的数据)

任何建议都是受欢迎的

用于复杂应用程序的WPF MVVM

由于处于设计阶段,建议模式和实践要容易得多,您的问题不是很清楚,所以我将解决您提出的每一点。

我必须通过代码控制视图,因为我必须根据用户权限启用、禁用或隐藏元素。此外,在TreeView中,我必须根据项目类型(内部逻辑)和用户权限的依赖性来控制TreeViewItems的ContextMenu。

这听起来很简单,在这种情况下使用MVVM设计模式很可能需要IValueConverter将视图模型Boolean属性转换为视图友好的Visibility值。这就解释了你是如何做到这一点的。

要显示的数据由存储过程加载到数据集(多个表)。

我建议研究存储库模式。这一点,再加上MVVM设计模式应该很适合您的需求。

MVVM和维护(与直接代码隐藏相比,MVVM的代码复杂性)以及控件可见性的所有稳定性有何经验。

MVVM的目的不是没有代码隐藏,而是确保代码位于正确的位置。代码隐藏并不是一件坏事,它是视图相关的代码。这里有一个更详细的答案。

在您的场景中,您很可能需要视图模型中的属性来指示用户是否有权查看某些控件,我假设这些权限在数据库中,因此这些属性需要存在于视图模型中,因为您无法从视图访问数据库。我希望这有点道理。

MVVM比代码隐藏解决方案更具可维护性,因为视图模型与视图是解耦的,因此,如果视图发生更改,则视图模型不一定也需要更改。存储库和模型也是如此。

MVVM为更加灵活的解决方案铺平了道路。

我来自一个winforms世界,实现任何MVX风格的模式似乎都更麻烦,但在处理了WPF之后,我可以说MVVM是最好的方法。整个机构是开箱即用的。

首先,关键的好处是它实现了"视图"answers"模型"之间的真正分离。这意味着,如果/当您的模型需要更改时,它可以在不需要视图的情况下进行更改,反之亦然。

其次,您的"模型"可能具有"视图"所需的所有数据,但这些数据可能是您的"视图"以其他方式所需的。对于这些转换,需要"视图模型",而模型中的重复则需要这些更改。

您还可以使用"视图模型"来聚合存在于单独类/库中的模型部分,以便于"视图"处理更流畅的界面。您不太可能希望以用户希望或希望将数据呈现给他们的方式来处理代码中的数据。

除此之外,您还可以支持"视图"answers"视图模型"之间的自动双向数据绑定。

我也在这里推荐视频:http://blog.lab49.com/archives/2650

您所描述的场景几乎"非常适合"使用MVVM。只需在视图中使用绑定,就可以根据权限控制可见性。您不需要在视图中编写任何代码(除此之外,您还必须执行一些特定的UI操作),因为您的"数据"(模型)和显示(视图)之间的整个连接都是在视图模型中完成的。这也增强了可维护性,您可以在不更改视图模型的情况下触摸视图,反之亦然。一开始会有点让人不知所措,你必须创建许多看起来有点混乱的属性。

简而言之:

  • 视图:用户将看到的表单(布局)(显示数据)
  • ViewModel:(在某种程度上)"控制"视图并将其与数据(模型)连接的逻辑
  • 模型:您的业务逻辑

例如:在视图模型中,您可以设置属性的状态,该状态指示控件元素对用户是否可见,然后将该属性绑定到视图。在视图中,除了在XAML代码中绑定属性之外,您什么也不做。这是保持清洁的好方法。

我希望这有点帮助。

编辑:这是一个快速启动,这里有一些进一步的信息