我有一个遵循 MVVM 模式的 WPF 应用程序。到目前为止,该应用程序定义了两个 View 和 View 模型:
两个 View 模型都需要访问其他 View 模型的多个属性。
例子:
LoginViewModel
有房产ProjectList
. ProjectsViewModel
也需要访问此属性。这只是一个简单的例子。以后会有几个
UserControls
所有这些都需要相互交互。创建一个巨大的 View 模型会更好吗?
UserControls
( View )设置为他们的DataContext
?如果不是,所有不同的 View 模型如何相互交互?评论:
这个问题与 this one 密切相关但采用不同的方法。
最佳答案
你绝对不应该制作一个巨大的“主视图模型”——这是一个与 god object 相同的反模式。 .
这里的关键思想是您的 View 模型不需要访问其他 View 模型的多个属性;相反,所有 View 模型都需要访问特定的信息。
现在,您很可能在实例化时将此信息注入(inject)每个 View 模型。不要这样做,而是为每个 View 模型提供对服务的引用——通过属性和/或方法公开此信息的应用程序模块。如果信息本质上非常简单,则可以以标量值的形式公开,如果比这更复杂,则可以以模型的形式公开。
从示意图上看,这看起来像
/--------------\
| ViewModelA |
| | <=======\
| | |
\--------------/ | <--- information is pulled /================\
+=========[model]===[model]====== | Service |
/--------------\ | \================/
| ViewModelB | |
| | <=======/
| |
\--------------/
服务应该是 injected在构建时进入 View 模型(手动或通过 DI 容器,如果您正在使用)。每个 View 模型应该只需要对服务的引用和足够的信息来告诉服务它对哪个模型感兴趣;然后它将从服务中请求该模型并基于此填充其“有趣”属性。
这种做事方式比简单地构建 View 模型对象并在外部设置其属性更复杂,但它会让您的应用程序变得复杂而不会变得难以管理。
例如,如果有很多 View 绑定(bind)在不同的 View 模型上,并且这些 View 模型以复杂的方式依赖于许多模型,那么一种理智的工作方式是:
如果一切都通过服务路由,这是可能的。想象一下保持一切同步需要什么 - 应对的唯一方法是将所有信息放入一个巨大的 View 模型中并从其他所有内容中引用它。丑陋。
关于wpf - MVVM 中 View 模型的交互,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/14361687/