WPF-保持ViewModel与WPF无关是一个好主意吗?

WPF-保持ViewModel与WPF无关是一个好主意吗?,wpf,model-view-controller,viewmodel,Wpf,Model View Controller,Viewmodel,在本主题中,我真的想了解人们在WPF中试图将所有WPF关注点排除在ViewModels之外的经验 干杯 AWC我个人的指导原则:是的,如果很容易做到的话。我真的很喜欢视图-视图模型方法中关注点的分离,但是因为我非常确定,如果没有WPF,我永远不会使用我的视图模型,我不会为了避免WPF引用而让代码变得更复杂或可读性更低。我一直发现ViewModel对我来说最有用的一件事就是将对象访问整理到Dispatcher线程上,以避免所有关于“此对象只能从UI线程访问”的尴尬错误。我想说,这与WPF不可知论相

在本主题中,我真的想了解人们在WPF中试图将所有WPF关注点排除在ViewModels之外的经验

干杯


AWC

我个人的指导原则:是的,如果很容易做到的话。我真的很喜欢视图-视图模型方法中关注点的分离,但是因为我非常确定,如果没有WPF,我永远不会使用我的视图模型,我不会为了避免WPF引用而让代码变得更复杂或可读性更低。

我一直发现ViewModel对我来说最有用的一件事就是将对象访问整理到Dispatcher线程上,以避免所有关于“此对象只能从UI线程访问”的尴尬错误。我想说,这与WPF不可知论相冲突,所以这不是一个普遍的规则,你应该努力成为不可知论者。当然,让ViewModel保存ListBoxItems之类的集合不是一个好主意。分离很好,但你必须对技术的需求做出一些让步。

AWC

根据我的经验,最好的做法是不要将所有WPF关注点都排除在视图模型之外。我不是在谈论视图特定类(列表框、文本块等),但我们应该始终记住,管理对UI线程的访问是WPF的一个重要部分,应该从ViewModel中维护它。这是因为视图只负责提供一个清晰的模板来表示VM提供的数据。是ViewModel决定是否应该异步检索数据,以及在什么情况下应该绑定数据——以上暗示使用Dispatcher来管理对UI线程的访问。所以我的答案是:不要忘记WPF不仅仅是一个视图类

我相信您想问,开发人员是否不应该担心VM类中的视图。如果我是对的,答案是肯定的,他们不必担心。ViewModel只是一个向匿名演示者(View)提供完整数据/命令集的层,它不关心绑定视图将使用提供的数据的哪一部分,也不关心数据将如何显示


我希望我的回答是有帮助的。如果您还有任何问题,请随时提问。

我认为这几乎总是可能的,只要您不介意多写一点代码。:)

想想您可以在ViewModel端以某种方式表示的内容:

  • 控制-坏主意,原因不计其数
  • 笔刷-可以轻松地移动到转换器输出、静态资源和模板
  • 枚举值,如可见性等-同样,转换器是您在这里的朋友;布尔到可见性,X到可见性,等等
  • 事件处理程序-它们成为“新世界”中的ICommand
  • 调度员:这是我偶尔会“欺骗”的一件事,但每次我都觉得自己很脏
    我不知道,也许我只是一个纯粹主义者,但如果我在视图模型的顶部看到任何“使用System.Windows”或“使用System.Windows.Controls”,我知道我已经找到了一个简单的方法来解决以后可能会回来咬我屁股的问题。

    我不同意-ViewModel的观点不是用来处理视图和模型之间的阻抗不匹配吗?我认为您不需要保持ViewModel 100%WPF免费-虚拟机可以帮助您解决问题。

    +1。同意:)。只有Silverlight可以在“不使用”WPF的情况下使用ViewModel。但这些技术非常相似…我认为不使用ICommand实现MVVM是不可能的,将更改(如NotifyCollectionChanged)分派到UI线程,并在model和viewmodel中实现INotifyPropertyChanged,所以我必须同意…我将分派器包装在上下文接口中,以便使用ExecutionContext,SynchronizationContext和Dispatchers在我的MVVM库中我喜欢的任何地方。此外,我认为NotifyCollectionChanged需要Dispatchers真的很烦人。但是,您可以通过自定义CollectionView来避开这一实现。副作用是冗长的xaml。