MVVM - 与 WPF 命令绑定标准有关答案

【问题标题】：MVVM - Pertaining to WPF command binding standardsMVVM - 与 WPF 命令绑定标准有关
【发布时间】：2012-07-14 05:54:13
【问题描述】：

我认为我对 MVVM 设计模型有很好的理解，但是我对 WPF、命令绑定以及我们应该如何使用它们有意见。

要将命令直接绑定到 XAML，我们需要在 ViewModel 中实现 ICommand 接口。现在，ICommand 接口是 PresentationCore.DLL 的一部分，如果我错了，请纠正我是 WPF 的一部分，而不是基本的 .NET 框架。

ViewModel 和 Model 的全部意义不在于它应该完全独立于 UI 吗？例如，如果我在 ViewModel 中实现 ICommand 并将其用作数据上下文以绑定来自 XAML 的命令，那么我的 ViewModel 是否依赖于 WPF 框架（特别是 PresentationCore.Dll）。

我的意思是，如果我要去尝试在 Windows 窗体环境中使用我的模型和视图模型，我将不得不引用 PresentationCore.DLL，即使我不需要它，因为我使用 Windows 窗体不是WPF 框架。

这对我来说似乎有点奇怪，我在这里遗漏了什么吗？是否有另一种方法可以让我的模型和视图模型完全独立于 UI 和 UI 框架，但仍然能够利用 XAML 中的命令绑定？

提前致谢！

【问题讨论】：

此时我自己的唯一解决方案是创建两个视图模型，有一个 XXXViewModel 和一个 XXXViewModelWPF，它继承自 XXXViewModel 并包含所有与 ICommand 相关的东西，然后 XXXViewModelWPF 类简单地变成 WPF只要。有没有更好的办法？谢谢

标签： wpf design-patterns mvvm commandbinding

【解决方案1】：

我也遇到过这种问题，但不是在 wpf 中，而是在 POCO 课程中。我所做的是在两个不同的程序集中创建了两个部分类。就像您在 VM 项目中创建一个不依赖于 presentationcore.dll 的部分类，并在另一个实现 ICommand 内容的程序集（例如 WPFVM）中创建其部分类。现在，对于 Winforms 的东西，只将 VM 项目引用添加到 View 项目，对于 WPF 的东西，将 VM 和 WPFVM 的引用添加到 View 项目。我希望这会有所帮助。

【讨论】：

感谢伦理逻辑，我已经决定这样做了，除了使用 Partial 类，我将为每个 ViewModel 创建一个名为 XXXViewModelWPF 的后代类，该类具有 ICommand 属性。正如您所说，这样我就不会在我的 Windows 窗体实现中包含 XXXViewModelWPF！这是个好主意，谢谢。

【解决方案2】：

MVVM 的目的是让视图只是一个视图，仅此而已。将 ICommands 放入视图模型有助于实现这一点，因为它将代码从视图中拉出。你会遇到问题的地方是如果你必须访问视图上不是依赖属性的东西，这意味着你不能绑定到它。

【讨论】：

谢谢你的回答，所以我对MVVM模型的解释不正确？ ViewModel 的重点不是从逻辑中抽象视图，而是更多地从视图中删除所有代码。因此，如果我要将程序移至 Windows 窗体，我将不得不重新编写 ViewModel 和 View，而不仅仅是 View？我认为设计模式的重点是限制 UI 设计更改时所需的返工？
MVVM 是专门为 WPF 设计的。我不知道它在 Windows 窗体上的效果如何。我同意限制返工，但是由于 WPF 和 Winforms 是如此不同，我不知道即使在 viewmodel 中没有 ICommmand 切换会有多么容易
好的，谢谢，我真的没有看到在 Windows 窗体应用程序中使用 ViewModels 和 Models 的问题，除了 ICommand 实现。例如，Windows 窗体控件可以包含对 ViewModel 的引用，并根据需要挂钩其 OnPropertyChanged 事件以使其自身无效。 Paint 消息将简单地根据 ViewModel 的当前状态进行绘制。我想我会在原始问题帖子的想法中使用我的评论，你能想到其他方式吗？

【解决方案3】：

在我看来，MVVM 很受 WPF、Silverlight 的欢迎，因为它自然适合它。 XAML 中的数据绑定概念允许使用单个属性（即 DataContext）来桥接视图和视图模型。由于您的逻辑不再与控件相关联，因此您可以获得更好的可测试性、设计代码分离和可维护性。您也可以在其他地方实现 MVVM 模式，但在 WPF 和 Silverlight 中，由于它的数据和命令绑定支持，它很容易适应。我在某处读过，不要虔诚地接受模式。它们旨在使您的生活更简单，而不是在遵循它时给您带来更多问题。对于 Winforms，我认为有更好的模式，如果您专注于重用业务逻辑，请将它们从 ViewModel 中移出以分离类，例如服务提供者或服务代理，并在 Winforms 和 WPF 应用程序之间共享它们。

【讨论】：

感谢 Moble Joseph，我想有人可以这样做，但对我来说，在不直接访问信息的情况下将所有业务逻辑抽象到单独的类中会带来更多的不便适用于这些业务规则。所有数据都需要传递给类。我仍然认为我最好的选择是为命令创建特定于 WPF 的后代 ViewModel，除非我没有正确理解您？
那么目前您在这些命令中执行业务逻辑？您不会使用某些数据传输对象将业务规则分离到单独的类中吗？
逻辑不是很复杂，不能保证，程序不使用数据库作为后端，它只有存储在模型中的对象的状态信息，然后视图模型负责通知通过事件查看更改（在本例中为 PropertyChanged 事件）。所以是的，程序的所有逻辑都在 ViewModel 内部，据我了解，基本的 MVVM 仅占模型、ViewModel 和 View 任何额外的东西都在 MVVM 之上？如果您想知道它是一个拼字游戏解决方案。然而，求解器代码被抽象为单独的类

【解决方案4】：

这在 .NET 4.5 中发生了变化

【讨论】：

感谢这个 jan，我不知道微软是否有人在这里阅读了我的 cmets 并决定移动它，但现在它已成为系统中 .NET 基础框架的一部分，哇！跨度>