首页 > 解决方案 > 重构 ViewModel

问题描述

背景:
我正在处理根据 MVVM 模式没有良好分离的 WPF 解决方案。我需要改进架构、可读性等。我当前的问题是我的 MainVM 具有大量依赖项。MainVM 对应于 MainWindow 视图。MainVM 在启动时创建,并作为属性保存应用程序的所有其他 ViewModel。这个 MainVM 被传递给命令的所有调用(实现 ICommand 的调用),如果某些功能需要它自己的 ViewModel,它会引用 MainVM 并读取包含所需 ViewModel 的相关属性。另一个问题是 ViewModels 没有从 Models 中分离出来。我的想法是为 ViewModel(理想情况下是模型,但此时很难实现分离)创建一个“存储”,并从该存储而不是 MainVM 访问所需的 ViewModel。
我的应用程序不存储任何内容,因此此 ViewModels 存储的生命周期将与应用程序的生命周期(静态)相同。

现在回答我的问题(改写):
1 - 从一个“主要”视图模型访问视图模型是常见的做法吗?
2 - 在 WPF 应用程序中为 ViewModels 和 Models 使用单独的存储可能有哪些缺点?
3 - 命令(实现 ICommand 的命令)是否应该依赖于 ViewModel?

改写的问题:1 - 在 WPF 应用程序中将 ViewModel 存储在哪里?
2 - 是否可以使用存储库模式将模型存储在 WPF 中?
3 - 没有修改

标签: c#wpfmvvmrefactoring

解决方案


1 - 从一个“主要”视图模型访问视图模型是常见的做法吗?

答:不。这是一个非常糟糕的设计(如果我称之为设计)。ViewModel 的设计方式应使其与父级和子级无关,这样即使将来其层次结构发生变化,也不会影响任何其他模块。它应该只处理它所支持的视图的属性、命令、事件。与子视图模型或父视图模型的任何通信都应通过事件发生。它绝对不应通过直接引用来引用父虚拟机或子虚拟机的属性。通过这种方式,您将拥有可维护、可测试的应用程序,并且不会遇到您现在所处的情况。

2 - 在 WPF 应用程序中为 ViewModels 和 Models 使用单独的存储可能有哪些缺点?

答:我假设存储是指 ViewModel 将通过其属性和命令向 View 公开的 Model 对象。理想情况下,此模型应该是您的应用程序的业务对象。请注意,单个 ViewModel 可以有多个模型,具体取决于视图设计和功能。但是您永远不应该从模型访问 VM,我认为您在问题中暗示了这一点。如果您没有不必要地将您的视图分解为微视图以拥有数以万计的视图模型和模型,那么您应该没问题。

3 - 命令(实现 ICommand 的命令)是否应该依赖于 ViewModel?

Ans: 命令也应该以一种可以跨视图重复用于类似类型的操作的方式编写。


推荐阅读