2

实际上，在这个主题中，我想知道人们尝试将所有 WPF 问题排除在 WPF 中的 ViewModel 之外的经验。

干杯

AWC

4

5 回答 5

4

我的个人指导方针：是的，如果它很容易做到的话。我真的很喜欢View - ViewModel 方法的关注点分离，但是因为我很确定我永远不会在没有 WPF 的情况下使用我的 ViewModel，所以我不会为了避免 WPF 引用而使我的代码更复杂或更不可读.

于 2009-12-21T10:30:14.907 回答
1

AWC,

根据我的经验，最好的做法是不要将所有 WPF 问题排除在 ViewModel 之外。我不是在谈论 View 特定的类（列表框、文本块等），但我们应该始终牢记管理对 UI 线程的访问是 WPF 的重要组成部分，我应该在 ViewModel 中对其进行维护。这是因为 View 只负责提供一个清晰的模板来呈现 VM 提供的数据。是 ViewModel 决定是否应该异步检索数据以及在什么情况下应该绑定数据 - 上面暗示使用 Dispatcher 来管理对 UI 线程的访问。所以我的回答是：不要忘记 WPF 不仅仅是一个 View 类。

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

我希望我的回答有帮助。如果您还有其他问题，请随时询问。

于 2009-12-21T14:02:16.487 回答
1

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

想想你可以在 ViewModel 端以某种方式表示的东西：

  1. 控制 - 坏主意，原因不胜枚举。
  2. 画笔 - 可以轻松移动到转换器输出、静态资源和模板。
  3. 枚举值，如 Visibility 等 - 同样，转换器在这里是您的朋友；bool 为可见性，X 为可见性等。
  4. 事件处理程序 - 这些成为“新世界”中的 ICommands
  5. 调度员：这是我偶尔会“作弊”的一件事，但每次我都觉得很脏。:)

我不知道，也许我只是一个纯粹主义者，但如果我在我的视图模型顶部看到任何“使用 System.Windows”或“使用 System.Windows.Controls”，我知道我已经轻松了摆脱可能会回来咬我屁股的东西。

于 2009-12-21T19:47:45.520 回答
0

我不同意 - ViewModel 的重点不是处理 View 和 Model 之间的阻抗不匹配吗？我认为您不需要让 ViewModel 100% WPF-free-VM 可以帮助您。

于 2009-12-21T19:52:53.487 回答
-1

我一直发现 ViewModel 为我做的最有用的事情之一就是将对象访问编组到 Dispatcher 线程，以保存所有那些关于“只能从 UI 线程访问该对象”的尴尬错误。我会说这与 WPF 不可知论相冲突，因此你应该努力做到不可知论并不是一个普遍的规则。当然，让您的 ViewModel 持有例如的集合并不是一个好主意。ListBoxItems 或类似的东西。分离很好，但你必须对技术的需求做出一些让步。

于 2009-12-21T11:22:07.443 回答